[微服务设计]1_微服务

摘要：微服务设计应当是面向服务、适配团队、循序渐进的设计。

目录

开篇引言

微服务

什么样的服务是健康的服务

什么是微服务

面向服务的架构

微服务较传统单体架构多的行为

微服务行为带来的问题

微服务解决的问题

---

开篇引言

在之前的工作中，有接触过一些微服务的设计方法，例如按照业务职责划分、设计微服务时该考虑的特性……

享受过微服务带来的好处，如快速修改服务、简化部署。也应对过微服务带来的挑战，追踪一个问题跨越数十个服务等。

也了解过一些微服务设计“哲学”——什么“不追求最佳实践就是最佳实践”、“适合团队的微服务才是最好的微服务”等……零零散散，说出来也结结巴巴。

那么，该怎么成体系更深入的了解微服务呢？

从《微服务设计》这本书开始吧。

文章按照自己的理解进行了内容补充和编排，《微服务设计》阅读起来会更轻松，文章更适合当做综合性笔记用于检索。

微服务

什么样的服务是健康的服务

一个健康的服务应具备：功能正确、性能高效、可用性高、可维护性强、健壮抗压、协作顺畅。它通过技术（如容错、监控）和设计（如自洽、单一职责）实现，既满足业务需求，又能在复杂环境中稳定运行。健康状态需通过指标量化并持续优化。

服务最开始是单体服务，随时间演化，代码库变得臃肿庞大。

所有功能代码耦合在一起。

此时，服务开始变得不健康，会有高耦合、低拓展性、可用性差、维护困哪、开发效率低、健壮性不足的等问题。且所有功能耦合在一起，缺乏隔离和灵活性。

微服务架构正是针对这些问题提出的改进方案。

一些指标定义如下：

1. 功能性（Functional Health）

• 正确性：服务按预期完成业务功能，无逻辑错误。

  • 例子：订单服务能准确创建订单并返回结果。

• 一致性：数据和状态符合业务规则。

  • 例子：支付成功后库存同步扣减。

2. 性能（Performance Health）

• 低延迟：响应时间短，满足用户体验（通常<200ms）。

  • 例子：用户查询订单状态不超过100ms。

• 高吞吐：能处理预期并发量。

  • 例子：支持每秒1000次请求。

• 资源利用合理：CPU、内存、I/O不过载。

  • 例子：内存占用稳定在50%以下。

3. 可用性（Availability Health）

• 高可用：服务 uptime 高（如99.9%），宕机时间少。

  • 例子：年宕机不超过8小时。

• 容错：单点故障不影响整体功能。

  • 例子：依赖服务超时，触发熔断返回默认值。

• 自愈：能自动恢复（如重启、重试）。

  • 例子：Kubernetes检测Pod崩溃并重启。

4. 可维护性（Maintainability Health）

• 清晰边界：职责单一，接口明确。

  • 例子：支付服务只处理支付，不混杂订单逻辑。

• 可观测：提供日志、指标、追踪，便于诊断。

  • 例子：集成Prometheus监控请求延迟。

• 易扩展：代码和架构支持快速迭代。

  • 例子：新增支付方式只需改支付服务。

5. 健壮性（Robustness Health）

• 异常处理：能优雅应对错误，不崩溃。

  • 例子：输入非法参数时返回400而非500。

• 流量控制：防过载（如限流、降级）。

  • 例子：每秒超1000请求时限流。

• 安全性：防止攻击（如SQL注入、DDoS）。

  • 例子：使用OAuth认证。

6. 协作性（Collaboration Health）

• 接口稳定：API契约不随意变更。

  • 例子：/orders接口保持向下兼容。

• 通信高效：与其他服务协同顺畅。

  • 例子：异步事件通过Kafka可靠传递。

• 数据自治：不依赖其他服务的数据源。

  • 例子：自带订单数据库。

健康服务的量化指标

• SLA（服务级别协议）：

  • 可用性：99.9%。

  • 响应时间：P95 < 200ms。

• 错误率：低于0.1%。

• 资源使用率：CPU<70%，内存<80%。

• 告警恢复时间：MTTR（平均修复时间）<30分钟。

什么是微服务

微服务就是协同工作的小而自洽的服务。

定义：

“微服务的协作”——是微服务设计中的重要一环，需要考虑因为微服务带来的“微服务通信”、“微服务监控”、“微服务安全”等问题。

“小”——“微服务该多小”的设计是一个很考验领域划分能力的事情，但是据实际工作经验来看，这更多的跟团队架构相关。“组织架构很大程度上决定了软件架构”。

“自洽”——生命周期独立（开发、测试、部署、升级独立）不受其他服务牵制；功能独立；数据自洽（有自己的数据存储）。

面向服务的架构

从个人的经验来看，生产中中小型企业很难做到让所有服务都处于健康的状态。多数企业也不会以技术位驱动进行产品或项目的开发。

从面向服务的角度来说，拥有微服务带来的好处的同时，也拥有了微服务带来的问题，如通信消耗、监控、日志等。

需要铭记的是：系统架构的演变并非一蹴而就，而是一个循序渐进的过程。不要期待一步到位，逐步优化和调整才是正道。

微服务较传统单体架构多的行为

服务拆分：将功能分解为多个独立服务。

分布式部署：每个服务单独运行于不同进程或节点。

接口通信：服务间通过API（如REST、gRPC）或消息队列（如Kafka）交互。

独立数据存储：每个服务拥有自己的数据库。

独立生命周期：服务单独开发、测试、部署。

动态伸缩：按需调整单个服务的实例数。

事件驱动：异步通信和事件订阅（如支付完成通知订单）。

微服务行为带来的问题

复杂度增加：管理多个服务、通信和部署更复杂。

网络开销：服务间调用引入延迟和带宽消耗。

数据一致性挑战：分布式数据难保持强一致性，需依赖最终一致性。

故障排查难：问题跨服务传播，需分布式追踪（如Zipkin）。

运维负担：监控、日志、容器管理（如Kubernetes）成本高。

接口不稳定：服务间契约变更可能导致兼容性问题。

资源分散：多服务运行可能浪费资源。

微服务解决的问题

耦合过高：单体模块紧耦合，微服务解耦为独立单元。

扩展受限：单体全量伸缩，微服务按需扩容。

部署缓慢：单体全量部署耗时，微服务独立快速发布。

单点故障：单体崩溃影响全局，微服务隔离故障。

开发效率低：单体多人冲突，微服务团队自治。

技术僵化：单体技术栈单一，微服务支持多样化。

性能瓶颈：单体资源竞争，微服务分散负载。

总体而言，微服务的设计旨在打造一种低耦合、高内聚、具备容错能力、可扩展性强且适应敏捷开发的架构模式。它带来了“技术异构性”、“弹性伸缩”、“灵活扩展”、“简化部署”、“与组织结构对齐”、“可组合性”以及“优化可替代性”等显著优势。