作为微服务架构的忠心拥趸，虽然有时也会对其感到不爽。使用微服务时，我时常能感受到“小中见大”、“稳中有快”等理念，另一方面也会警惕“厨子太多烧坏了汤”。
回顾 2014 年，公司正在通过采用微服务架构实施数字化转型。那时数字化、转型和微服务这些词对我就是天籁之音。
作为一名解决方案架构师，我非常希望能了解这种新模式。为了跟上技术前沿趋势，我阅读了大量微服务架构相关的文章，与我的网络技术负责人交流，并研究了一些适用的用例。
那时我发自内心地相信微服务架构，确信单体应用将会消亡。
此后，我服务过的每家公司都已采用或正在采用微服务架构。虽然其中一些公司的领导团队并没能说服组织为什么要选择微服务，一个普遍的回答是：“其他公司都在这样做，在每次会议上大家都说微服务是一种改变游戏规则的方式，所以我们也这样做吧。”
通过为各个业务领域中的多家公司提供体系结构和设计支持，我发现将现有的单体应用重新架构为微服务架构需要付出大量的耐心、时间和经验。
在给出我在采用微服务中的五点切身体会之前，首先重新审视一下什么是微服务？
有说法提出，这种架构样式事实并没有一个的标准定义，只是存在一些“围绕组织和业务能力、自动部署，端点智能、对语言和数据分散控制”的特征。
在我看来，如果一个组织必须具备上述所有特征才能去使用微服务，那么我们就不仅是在谈论技术变革，而是在推动组织内的重大文化变革。
下面给出我在实践微服务中的五点主要体会。
![]()
传统的软件开发方式中，开发团队一起构建一个单体应用软件，进而由生产支持团队管理该软件。在这种方式中，生产支持团队作为软件的新所有者，通常并不完全了解组件的构建过程，例如代码的逻辑，所使用的技术等。
他们的核心工作是确保满足业务需求的生产系统能正常地运行，团队之间通常也没有定义有效的沟通途径。生产系统中出现的问题将导致开发回滚到某个还原点，或是给出快速的短期修补。有时，生产代码中的一个微小问题将触发整个过程全部重新开始。而问题通常必须由原始开发团队解决，这导致整体延迟。
如果以瀑布式开发方式（即前期设计、集中式的版本发布流程、构建和部署）处理微服务，则存在巨大的风险。最终得到的可能是一个更复杂的系统，无法享受微服务所承诺的任何好处。
在微服务中，经常提及的是“产品”，而非“项目”。使用微服务方法，利益相关者（包括用户、程序、产品和技术人员）致力于产品这一共同目标。在投资、软件交付到维护的整个过程上，产品模式都不同于项目模式。
产品直接影响所提供的业务功能。不同于传统方法中构建单体应用需要多个团队参与，微服务模式支持单个团队完全负责构建和管理某一小部分软件。团队在产品模式下是稳定的、跨职能的，并以结果为导向的，独立完成“设计 - 构建 - 运行”全过程。
每个团队都是遵循统一报告层级的独立部门，根据路线图去分块构建独立的软件单元。某一层上的团队可将另一层上的团队视为他们的（内部）客户，相互协作去解决业务问题，而不是以权责交付的方式工作。
由于工程团队以产品模式工作，他们了解软件在生产中的行为，因此可以立即解决所有问题，避免产生延误。
CapitalOne 秉持 YBYO（You Build You Own，自己构建）理念，团队全权负责设计、构建、测试和部署生产环境中的软件。工程团队直接参与产品，并与用户互动。用户不断提供反馈，帮助团队构建高质量的产品。
要点：控制范围使团队可以更好地构建和管理微服务。产品模式支持与终端用户建立更紧密的合作、管理和构建关系。
![]()
我在加入 CapitalOne 之前曾任职另一家公司的团队，为公司的电子商务网站建立产品目录服务。该公司采用了微服务方法，产品目录服务以请求为准则，向最终用户提供产品列表。
由于我的团队控制着数据和目录数据库，因此选择 Java 和 SpringBoot 构建服务。这些编程语言支持丰富的软件库，我们对此非常满意。服务最终公开提供在面向最终用户的 API 网关上。
公司中同样还有其他几个团队，使用各自的技术来构建自己的服务。从产品的角度来看，每个功能都受到构建在异构平台上的各个服务的支持。这样的模型解决了一个重要的问题，那就是在招募和培训团队中，不必使用相同的技术堆栈构建单体应用。在微服务模型中，每个团队都可以选择适合自身业务需求的工具，据此招聘新的团队成员。
微服务是一种通过服务构建其中业务应用组件的体系架构。每个服务都是业务流程中的一个独立于其他服务的逻辑软件单元。这种不依赖于其他服务和技术选择的自由度，打开了探索新技术、构建本地软件组件以及基于服务定义范围进行设计的大门。
在 CapitalOne，软件产品与业务功能是保持一致的。各个业务线（lines of businesses，LOB）构建和管理自己的产品。跨职能的业务线主要是用于构建和管理企业产品的，例如满足所有 LOB 需求的数据湖和平台。
要点：松耦合和紧关联的原则，支持团队构建各种解决更大业务问题的产品。
![]()
微服务架构实际上是一种微组件架构。“微”指组件的粒度细，而不是指所暴露接口的粒度。微服务是以 API 为接口的组件，但并非所有的微服务组件都暴露 API。在从单体应用向微服务架构过渡中，我们可以保持暴露的 API 数量不变。
在这一过渡过程中，确定初始计划将需要几天甚至几个月的时间，反过来增加了初始阶段的前期成本。大型应用分解为微服务，可能需要更多团队的协作。其中持续存在着过度工程的风险，导致创建了比需求更多的微服务，增加了体系结构的复杂性。
我在加入 CapitalOne 之前曾任职的一个公司，确定了一些可迁移到微服务架构的单体业务应用。产品的愿景并没有发生改变，因为整体的业务功能没有改变。
公司招聘了更多的团队，期望这些团队担当起服务的所有者。公司根据发布时间表部署服务，但基础架构团队并未受到计划的影响，仍然掌控着生产系统。计划在启动两年后的进展不大，花光了预算。
如上的许多实例表明，公司内部团队应对微服务的实现做更好的沟通。实现数字化转型的不仅仅是应用的开发和新的技术，还需要在产品分析、预算估算、架构、部署程序的重新设计、基础架构扩展等过程上做大量的工作。过渡到微服务，需要时间、金钱，以及对业务问题看法上的重大转变。
要点：微服务并非只是一种架构方式，而是一种会影响到组织中每个团队的文化变迁。
![]()
采用微服务需要建立多个产品、服务和团队。在采用这种复杂的体系结构之前，组织必须确立一个扎实的路线图。
企业需要采用强大的企业级产品，支持各个团队以微服务方式工作，凝聚在一起。其中包括支持 API 文档的工具，以及源代码管理、问题追踪器和实现自动部署的工具等协作工具。
服务由工程团队构建，以 API 方式暴露在 API 网关上。API 网关类似于一个 REST API 的市场，是组织日常业务运营的骨干。一旦组织步入微服务方法的正轨，持续的服务流就能得以创建、升级、替换等。工程师可能并不知道每个服务的确切位置，由服务发现系统支持服务的自动检测，使得服务之间可以互相发现。
为了获得更好的性能和故障隔离，微服务组件需要一个专门的基础架构。每个微服务应具有自己的发布时间表，无需依赖于其他服务而随时部署到生产环境。因此，选择有效工具持续并实时监视和分析微服务的是至关重要的。
API 是微服务世界的接口，因此 API 的日志记录、性能监视和安全性也是组织中 IT 服务过程的关键。
构建有弹性的微服务，可遵循多种设计模式，例如，“重试模式”（Retry Pattern）通过透明地重试失败操作尝试连接到服务或网络资源，支持应用处理瞬态故障；“断路器模式”（Circuit Breaker pattern）支持应用在连接远程服务或资源时发生错误时能很好地处理故障。
这样避免了微服务生态系统中出现级联故障，进而提高应用的稳定性和弹性。在微服务中，每个服务都是独立的组件，每个功能和服务都可以扩展，而不必扩展整个应用。关键服务可部署多个实例，实现高可用性和更好的性能，而不会影响其他服务的性能。
要点：尽管过渡到微服务需在前期需投入大量的资源和工作，但随着时间和工作上的付出，以及自动化工具的使用，业务将从中受益，可快速向市场交付有质量产品。
![]()
并非所有的业务和用例都适用微服务。例如，团队必须构建具有很少功能的简单应用，或是大型单体应用无法拆分成较小的模块，或是不了解微服务体架构所带来的权衡。
此外，某些企业可能尚未具备快速开发和部署应用的能力，或是不需要持续监视应用或业务，因为发生故障的恢复时间较长对业务影响不大。
和所有其他工具一样，微服务只是一种工具，并非普适于所有业务问题的解决方案。业务优先于一切，底层系统则可以适应任何体系架构模式，无论是单体应用还是微服务。
在决定使用微服务之前，每家企业必须首先了解自身的业务需求，权衡利弊后再决定是否转向微服务。
CapitalOne 在完全采用云和微服务架构之前，投入了大量时间和精力研究微服务应用。有能力的领导、富有远见的产品团队和技术精湛的工程团队通力合作，使得 CapitalOne 实现了银行技术领导者这一目标。
要点：使用微服务并非免费的午餐。
使用微服务架构将导致基础架构的需求、成本和复杂性激增，那么企业为什么要采用微服务？具有大客户群的大公司，将通过在短时间内向客户提供优质的产品而蓬勃发展。他们的系统需要始终保持运行的状态，为分布在各个地区的客户提供服务。
微服务是一种有助于实现此目标的解决方案。在当今的世界中，随着云原生基础架构的出现、DevOps 交付管道的自动化以及容器的采用，公司应该研究一下微服务的优势。
需要指出的是，企业决定选用某种技术，并非完全因为别人用着很酷。相反，在采用微服务之前，我们需要花费时间和精力去了解这种架构模式，该架构与企业自身的相关性。希望我的切身体会能有助于读者深入了解微服务。
- END -
![]()
