从SOA到MSA（下）

SOA的实现通常可分为四个层次，如下图所示：

图：SOA频谱（Spectrum）

（1）JBOWS（Just-Bunch-of-Web-Services）

这是SOA实现的最初级阶段，通常是在IT部门而非业务部门主导下以一种近乎随机、非计划的模式生产出一堆以功能为导向的服务，而服务之间的协作、稳定性、可用性等通常难以保证。

（2）面向服务的集成（Service-Oriented Integration）

SOI是JBOWS的进阶模式，这种模式的特点是服务合同（Service Contract）以被集成的应用为中心，因此当应用发生变化时，服务合同也要被迫随之发生变化（改写）。（例如，当被集成的CRM应用从Sugar CRM更换为MS CRM时，由于两种CRM间不具有兼容性，构建在其上的所有服务合同都不可避免地要重新实现。）

（3）分层服务（Layered Service Model）

分层服务模式在《从SOA到MSA》的上集中有具体阐述，同时大家可参考‘SOA的三层架构’的图片。这种实现方法中业务流程、任务与数据仓库都可以以一种原子化（Atomic）的方式被实现。但是与SOI模式同样遇到的挑战是当业务需求逻辑发生变化后，各层服务通常需要随之变化，特别是底层的、被多个上层服务所引用的那些服务的变化会对系统的整体稳定性带来很大的挑战。

分层服务的另一个特点是，通常它的架构实现体现了组织机构的构成方式。如下图所示，左侧筒仓式的分层组织架构必然会导致系统设计架构也同样是筒仓式分层的。

Melvin Conway在1968年的结构化编程大会（National Symposium on Modular Programming）上发表的一篇论文中把这种现象概括为：

“organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations”—M. Conway

图：从筒仓式（silo）功能分组到筒仓式架构设计

（4）微服务架构（MSA）

MSA是SOA的高级阶段，具有如下特征：

·组件化：所谓组件化指的是可被独立替换与升级的软件单元，即服务。服务的通信机制通常变现为Web服务或RPC（Remote Procedure Call）调用。

·围绕业务能力的组织架构：MSA实现的关键远远超出单纯的技术范畴，它对组织机构（团队组建方式、成员技能与能力）改变也提出了要求。单就技术团队而言不再是按技能分层（如DBA层、中间件层、UI层）来组队，而是形成了跨功能团队（Cross-Functional Team），每个团队的目标是实现与维护完成某种业务需求的服务（见下图）。服务之间通过可跨平台，不依赖于某种语言的API来通信，并能相对独立地演化（升级、迭代）。

图： 跨功能团队→按业务能力划分的微服务

图： 跨功能团队→按业务能力划分的微服务

· 去中心化的管理（Decentralized Management）：系统高可扩展性的最大障碍就是中心化管理，因此MSA的实现过程中去中心化显得异常重要。上图展示的就是分布式的数据库满足多个微服务的应用需求。在可扩展数据库一节中我们提到过的数据库分区、分表其实都是去中心化的具体体现。

·基础架构自动化（Infrastructure Automation）：我们说云计算的发展，特别是XaaS发展过程中，自动化的趋势与需求越来越明显，特别是自动化的开发（准确地说是CAD模式，计算机辅助的开发）、测试、集成、部署与监控的五步一条龙DevOps模式越来越被企业所青睐。

· 面向失败的设计（Design for Failure）：面向失败的设计说法最早由Netflix公司提出。Netflix在AWS云上测试自己的各种MSA服务时，使用了各种自动化工具在生产环境中随机地破坏各种组件（硬件或软件），以测试系统自我监控与修复的能力。这种设计理念要求系统对自身每个微服务、组件都有精细化的监控与管理，并有适度的冗余以确保当部分服务被中断时，系统依然可以完成相应的工作。

最后，MSA通常也被称作精细化SOA（Fine-grained SOA），但是有如下几个基本原则来确保这种精细化不会被极致成为nano-service（也就是说过度精细化服务分工造成了服务间通信与服务维护的代价大于它们所带来的价值）：

·每个服务必须是提供显著的、有意义的功用的，如果拆分为过细的功能，就需要考虑把它们适度合并； ·可以把功能以库的方式实现（而不是以一种服务来存在）。

·本节END·