你有没有玩过乐高？不同形状的模块，只要接口匹配，就能快速拼出城堡、汽车等造型。其实在云计算、大数据时代，程序员搭建软件系统的思路，和搭积木非常相似！这背后的核心设计理念，就是大名鼎鼎的面向服务的体系结构（SOA，Service-Oriented Architecture）。
标准化组织The Open Group对SOA有明确的定义：SOA是一种面向服务的架构设计风格。而面向服务是一种以服务开发、服务结果为导向的思维模式，所谓服务通常有如下特点:
①自包含的。
②对服务的消费者是黑盒的。
③有明确输入/输出的可重复商业活动的逻辑表示。
④可由其他服务构成。
纵览云计算与大数据时代的各类技术框架与系统体系架构，它们的共同特征是注重可扩展性、敏捷性与弹性，以集群的整体业务（数据）处理能力及综合服务提供能力来弥补单一节点的性能劣势，以及对节点故障、上下线等因素的抗干扰能力强。
一、为啥需要SOA ？软件系统也需要团队协作
想像一家超大型物流仓库：每个货架是一个独立的 “数据仓库”，收银员、理货员、库存管理员各自忙碌。但如果库存系统突然崩溃，或者顾客临时改买其他商品，整个流程就会乱套。
传统软件系统就像这家物流仓库，各个功能模块（节点）各自为政，一旦某个环节出问题，整个系统都可能瘫痪。而SOA 就像给物流仓库配备了智能调度中心：
1）可扩展性：生意火爆时随时加开收银台（增加节点），不用重新装修超市（重构系统）；
2）弹性与敏捷：促销活动时快速调整货架布局（动态分配资源），库存不足时自动补货（自适应处理）；
3）抗干扰能力：某个员工请假（节点故障），其他同事能迅速接手工作（无缝切换）。
如果我们再结合各种XaaS平台（（比如云计算、软件即服务））以及SDX（软件定义的一切）——（可以理解为SOA的智能插件）框架，它们的共性可以简单归纳为：分层抽象化架构，层与层之间通过服务来通信，底层向上提供可被调用的服务接口。
XaaS：就像共享充电宝，不用自己买设备，随用随租，成本更低；
SDX：好比智能家居系统，用手机就能远程控制灯光、空调，灵活性拉满。
它们本质上都是基于 SOA 的分层架构，让系统更灵活、更高效。
二、典型SOA的3层架构
图1展示了典型SOA的3层架构：组件架构、服务体系架构与应用服务层体系架构。
①组件架构：作为最底层，组件架构向上提供可调用的编程接口。典型的如虚拟机、容器、IaaS、软件定义存储、软件定义网络等都会在这一层工作，它们直接与各种物理组件实现对接。
②服务体系架构：这一层承上启下，对下层组件提供的API进行抽象化、虚拟化，使上层架构不需要关心下层的实现细节，并提供通用的接口、可管理架构以及系统的逻辑视图给上层应用。
③应用服务层体系架构：调用与集成底层提供的服务接口，并专注于实现业务逻辑。
需要指出的是，SOA的概念是在第二平台的时代提出的，但其理念在第三平台（大数据、云计算、移动互联、社交）中依然适用。SOA通常需要兼顾第二、第三平台的需求，因此在体系架构设计上往往采用进化的方式。
再举个栗子：外卖平台是怎么运作的？顾客下单（顶层服务）→ 平台调度骑手（中层协调）→ 商家制作餐品（底层执行），这就是典型的分层结构。 在技术世界里，SOA 把系统拆成三层 “透明工厂”：
顶层（用户层）：直接和你打交道的界面，比如手机 APP、网页；
中层（服务层）：像 “翻译官”，把用户需求拆解成底层能理解的指令； 底层（数据层）：默默处理数据、存储信息，就像厨房的灶台和冰箱。 每层之间通过 “服务接口” 通信，就像外卖订单通过二维码、电话传递信息。
底层向上提供统一的 “服务菜单”，比如 “查询库存”“计算价格”，上层直接 “点菜” 调用，不用管具体怎么实现。
下面，我们来看一个直观一点的例子，一个典型的基于云架构的可扩展Web类应用SOA的3层架构，如图2所示。
在图2的左侧部分中，自上而下分别是：最上层提供了移动端或Web端的用户界面与接口实现；中间层提供了应用所需要的各种服务，如缓存服务、NoSQL数据库服务、索引服务、监听服务、聚集服务等；最底层则是实现各种业务功能与逻辑的具有领域特定性的服务器，例如CRM系统、采购系统、预约系统等，我们称之为记录系统(System ofRecord，SoR)。
很显然最底层的SoR通常会包含第二平台的系统，而SOA所要解决的问题就是让这些第二平台系统可以与第三平台的应用与服务对接。SOA主要由两大组件来帮助实现这种对接。
•聚集服务：对SoR的任何改动（写或更新、删除等操作）通过聚集服务来完成。而只读类服务则通过缓存、索引、信息推送或轮询等服务来实现（这样做的最大优点是让底层的传统SoR类系统可以免受直接的Web负载冲击）。
•事件驱动的架构(Event Driven Architecture，EDA)：通常有两种实现方法，这两种方法分别是企业服务总线(Enterprise Service Bus，ESB)和AtomPub。ESB基于服务者消息推送的设计理念，而AtomPub则基于消费者消息轮询的设计理念，二者适用的应用场景不同。ESB更适用于低时延应用，而AtomPub对时延有更高的容忍度。
SOA的实现通常可分为4个层次，如图3所示。
(1)JBOWS
只是一大堆Web服务(Just a Bunch of Web Services，JBOWS)是SOA实现的初级阶段，通常是在IT部门而非业务部门主导下，以一种近乎随机、非计划的模式生产出的一堆以功能为导向的服务，而服务之间的协作、稳定性、可用性等通常难以保证。
(2)面向服务的集成
面向服务的集成是JBOWS的进阶模式，这种模式的特点是服务合同以被集成的应用为中心，因此当应用发生变化时，服务合同也要被迫随之发生变化（改写）。例如，当被集成的CRM应用从Sugar CRM更换为MS CRM时，由于两种CRM间不具有兼容性，因此构建在Sugar CRM上的所有服务合同都不可避免地要重新实现。
(3)分层服务模式
在分层服务模式中，业务流程、任务与数据仓库都可以以一种原子化的方式被实现。但是与面向服务的集成模式遇到的挑战相同，即当业务需求逻辑发生变化后，各层服务通常需要随之变化，特别是底层的、被多个上层服务所引用的那些服务的变化会给系统的整体稳定性带来很大的挑战。
此外，分层服务的架构体现了组织机构的构成方式。如图4所示，左侧筒仓式分层组织架构必然会导致系统设计架构同样是筒仓式分层的。梅尔文·康威(Melvin Conway)在1968年发表的一篇论文中把这种现象概括为：任何设计系统的组织……必然会产生以下设计结果，即其结构就是该组织沟通结构的写照。
(4)微服务架构
微服务架构是SOA的高级阶段，具有如下特征：
①组件化：指的是可被独立替换与升级的软件单元，即服务。服务的通信机制通常变现为Web服务或RPC调用。
②围绕业务能力的组织架构：微服务架构实现的关键远远超出单纯的技术范畴，它对组织机构（团队组建方式、成员技能与能力）改变也提出了要求。单就技术团队而言，不再是按技能分层（如中间件层、用户界面层）来组队，而是形成了跨功能团队，每个团队的目标是实现与维护满足某种业务需求的服务。从跨功能团队转换为按业务能力划分的微服务如图5所示。服务之间通过可跨平台，不依赖于某种语言的API来通信，并能相对独立地演化（升级、迭代）。
③去中心化的管理：系统高可扩展性的最大障碍就是中心化管理，因此在微服务架构的实现过程中，去中心化显得异常重要。图6展示的就是分布式的数据库满足多个微服务的应用需求。在与可扩展数据库相关的内容中我们提到过的数据库分区、分表，其实都是去中心化的具体体现。
④基础架构自动化：我们说云计算的发展，特别是在XaaS发展过程中，自动化的趋势与需求越来越明显，自动化的开发[准确地说是计算机辅助设计(Computer Aided Design，CAD)模式，计算机辅助的开发]、测试、集成、部署与监控的五步一条龙DevOps模式越来越被企业所青睐。
⑤面向失败的设计：这个说法最早由Netflix公司提出。Netflix在AWS上测试自己的各种微服务架构服务时，使用了多种自动化工具在生产环境中随机地破坏各种组件（硬件或软件），以测试系统自我监控与修复的能力。这种设计理念要求系统对自身每个微服务、组件都有精细化的监控与管理，并有适度的冗余以确保当部分服务被中断时，系统依然可以完成相应的工作。
微服务架构通常也被称作精细化SOA，但是有以下几个基本的原则来确保这种精细化不会被极致成为Nano-Service，也就是说过度精细化服务分工造成的服务间通信与服务维护的代价大于它们所带来的价值。
①每个服务必须是能被显著提供的、有意义的、公用的。如果服务被拆分为过细的功能，就需要考虑把功能适度合并。
②可以把功能以库的方式实现（而不是以一种服务来存在）。
三、服务思维：从 “完成任务” 到 “提供价值”
这里我们要聊一个用户体验感的问题，这就需要服务思维。如果说传统编程就像按着菜谱做菜且做饭人必须严格按照步骤执行的话，而 SOA 就是“面向服务思维”，它更像是 “私厨”——
可复用：炖好的鸡汤既能单独上桌，也能用来煮面，代码不用重复写；
标准化：所有服务都有统一的使用说明书，就像电器的国标插头；
松耦合：更换某个功能（比如把菜刀换成碗），不影响其他环节。
下次再听到SOA，不妨想象成是一个乐高，每个模块都能随时插拔、自由组合，这就是现代软件系统高效运作的秘密!啧啧！88~
（文/Ricky - HPC高性能计算与存储专家、大数据专家、数据库专家及学者）
扫一扫
67
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
