[微服务设计]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）成本高。
接口不稳定：服务间契约变更可能导致兼容性问题。
资源分散：多服务运行可能浪费资源。
微服务解决的问题
耦合过高：单体模块紧耦合，微服务解耦为独立单元。
扩展受限：单体全量伸缩，微服务按需扩容。
部署缓慢：单体全量部署耗时，微服务独立快速发布。
单点故障：单体崩溃影响全局，微服务隔离故障。
开发效率低：单体多人冲突，微服务团队自治。
技术僵化：单体技术栈单一，微服务支持多样化。
性能瓶颈：单体资源竞争，微服务分散负载。
总体而言，微服务的设计旨在打造一种低耦合、高内聚、具备容错能力、可扩展性强且适应敏捷开发的架构模式。它带来了“技术异构性”、“弹性伸缩”、“灵活扩展”、“简化部署”、“与组织结构对齐”、“可组合性”以及“优化可替代性”等显著优势。