接前一篇文章：软考 系统架构设计师系列知识点之云原生架构设计理论与实践（12）

所属章节：

第14章. 云原生架构设计理论与实践

          第3节 云原生架构相关技术

14.3.2 云原生微服务

1. 微服务发展背景

过去开发一个后端应用最为直接的方式就是通过单一后端应用提供并集成所有的服务，即单体模式。随着业务发展与需求不断增加，单体应用功能愈发复杂，参与开发的工程师规模可能由最初几个人发展到十几人，应用迭代效率由于集中式研发、测试、发布、沟通模式而显著下滑。为了解决由单体应用模型衍生的过度集中式项目迭代流程，微服务模式应运而生。

微服务模式将后端单体应用拆分为松耦合的多个子应用，每个子应用负责一组子功能。这些子应用称为“微服务”，多个“微服务”共同形成了一个物理独立但逻辑完整的分布式微服务体系。这些微服务相对独立，通过解耦研发、测试与部署流程，提高整体迭代效率。此外，微服务模式通过分布式架构将应用水平扩展和冗余部署，从根本上解决了单体应用在拓展性和稳定性上存在的先天架构缺陷。但也要注意到，微服务模型也面临着分布式系统的典型挑战：如何高效调用远程方法、如何实现可靠的系统容量预估、如何建立负载均衡体系、如何面向松耦合系统进行集成测试、如何面向大规模复杂关联应用的部署与运维。

在云原生时代，云原生微服务体系将充分利用云资源的高可用和安全体系，让应用获得更有保障的弹性、可用性与安全性。应用构建在云所提供的基础设施与基础服务之上，充分利用云服务所带来的敏捷性、稳定性，降低应用架构的复杂性等。云原生的微服务体系也将帮助应用架构全面升级，让应用天然具有更好的可观测性、可控制性、可容错性等特性。

2. 微服务设计约束

相较于单体应用，微服务架构的架构转变，在提升开发、部署等环节灵活性的同时，也提升了在运维、监控环节的复杂性。设计一个优秀的微服务系统应遵循以下设计约束：

（1）微服务个体约束

一个设计良好的微服务应用，所完成的功能在业务领域划分上应是相互独立的。与单体应用强行绑定语言与技术栈相比，这样做的好处是不同业务域有不同的技术选择权。比如推荐系统采用Python实现效率可能比Java要高效得多。从组织上来说，微服务对应的团队更小，开发效率也更高。“一个微服务团队一顿能吃掉两张披萨饼”、“一个微服务应用应当能至少两周完成一次迭代”，都是对如何正确划分微服务在业务领域边界的隐喻和标准。总结来说，微服务的“微”并不是为了微而微，而是按照问题域对单体应用做合理拆分。

进一步地，微服务也应具备正交分解特性，在职责划分上专注于特定业务并将之做好，即SOLID原则中单一职责原则（Single Responsibility Principle，SRP）。如果当一个微服务修改或者发布时，不应该影响到同一系统里另一个微服务的业务交互。

（2）微服务与微服务之间的横向关系

在合理划分好微服务间的边界后，主要从微服务的可发现性和可交互性处理服务间的横向关系。微服务的可发现性是指当服务A发布和扩缩容的时候，依赖服务A的服务B如何在不重新发布的前提下，如何能够自动感知到服务A的变化？这里需要引入第三方服务注册中心来满足服务的可发现性；特别是对于大规模微服务集群，服务注册中心的推送和扩展能力尤为关键。微服务的交互性是指服务A采用什么样的方式可以调用服务B。由于服务自治的约束，服务之间的调用需要采用与语言无关的远程调用协议，比如REST协议很好地满足了“与语言无关”和“标准化”两个重要因素，但在高性能场景下，基于IDL的二进制协议可能是更好的选择。另外，目前业界大部分微服务实践往往没有达到HATEOAS启发式的REST调用，服务与服务之间需要通过事先约定接口来完成调用。为了进一步实现服务与服务之间的解耦，为服务体系中需要有一个独立的元数据中心来存储服务的元数据信息，服务通过查询该中心来理解发起调用的细节。伴随着服务链路的不断变长，整个微服务系统也就变得越来越脆弱，因此面向失败设计的原则在微服务体系中就显得尤为重要了。对于微服务应用个体，限流、熔断、隔仓、负载均衡等增强服务韧性的机制成为了标配。为进一步提升系统吞吐能力、充分利用好机器资源，可以通过协程、Rx模型、异步调用、反压等手段来实现。

（3）微服务与数据层之间的纵向约束

（4）全局视角下的微服务分布式约束

更多微服务设计约束详情请看下回。