关于SOA和微服务架构的一些思考

Posted 2021-04-14 四维部落

摘要：从技术角度看，SOA和微服务架构可以结合使用，企业整体层面的问题可以使用SOA的理念去思考和解决，而单个软件产品或者服务可以按需采用微服务架构来实现。然而，结合使用的真正挑战并非仅仅来自技术层面。

回忆十多年前，SOA开始流行的时候，倡导者们经常会拿出下面这张图（图1），并开始列举这类企业IT架构的各种弊端，其中最主要的有以下几条：

   1）相同的数据在多个系统间存在多份拷贝且相互不一致，无法在整个企业层面有效共享。

   2）相同或者相似功能在不同系统中重复建设，成本高效率低，无法快速应对客户需求变化。

   3）没有统一的技术架构标准和规范，各系统使用的技术、人员等各自为政，流程不规范，管理成本高，风险不可控。

图1

SOA倡导者宣称只要引入新的IT架构（图2），就可以解决上述问题，企业整体的IT建设和管理将从此走上统一高效、规范化、标准化的阳光大道。

图2

在SOA架构下，整个企业层面所有数据、信息、资源能够得到统筹考虑，并将可以重用和共享的数据和功能整合并封装为服务，不同应用通过组合不同的服务实现业务需求，同时SOA架构还规范了一系列技术标准，辅助建立了配套的管理流程。不可否认，对于企业整体来说，SOA的实践者们发现这种架构的确兑现了当初的建设目标，在较短的时间里，企业的整体IT技术和管理水平得到了显著的提升。

正当大家庆祝大功告成，以为可以从此快乐幸福生活下去的时候，新的挑战却在不知不觉中出现。近年来软硬件和通信技术的飞速发展带来了移动互联网应用的大爆发，再加上残酷的竞争让如今的软件产品和服务变成了快速消费品，单个产品功能简单但更新换代却非常快，海量客户会像病毒一样一夜之间突然出现或者消失。基于复用、统筹、标准化为核心思想的企业级SOA架构显然无法应对这种快速消费式的更新换代需求，而微服务架构就在这样的背景下横空出世（图3）。

图3

在微服务架构下，一个应用被切分为多个独立部署的服务，每一个微服务本身是一个功能单一的系统，它们之间松散耦合，一般使用异步机制通信，单个应用拥有某一个业务场景下的完备功能，这种架构的优点就是每个微服务应用可以完全独立的按照自己的节奏、方法、技术路线快速地更新迭代而不依赖或者影响其他应用。比较而言，SOA架构中服务的变更会相对较慢，因为需要考虑复用、规范、对现有其他服务或系统的影响等等。

相比10多年前，现在的世界变化得实在太快，这让已经实现SOA架构的传统企业感觉有些措手不及，难道我们刚刚建成的SOA架构就要被这个名不见正传的微服务架构所替代吗，在急于追赶这个快速变化的新时代之前，我们也需要冷静下来，看看微服务架构所面临的诸多挑战，下面列举了其中的一些：

   1）微服务很小，随着时间的推移，微服务数量会越来越多，从整体上看管理、运维的复杂度会越来越大。

   2）微服务应用互相独立，功能上的重复建设和数据上的冗余在不同产品不同微服务应用之间无法避免，复用和整合的难度极大。

   3）微服务之间是松耦合的分布式系统，使用异步通信，因此交易一致性和容错机制变得异常复杂，最终一致性成为了无奈的选择。

其实任何技术架构都有优缺点，对方的缺点可能就是己方的优点，从本质上讲，上述两种架构都是希望能够既可控又快速地应对需求的变化，只是采用的方法不同。SOA试图通过规范化、标准化的服务复用来应对变化、控制成本和风险，而微服务架构采用的则是将应用按产品功能拆小解耦，做到既能适应灵活迅速的变化又能让变化范围、成本和风险可控。

因此对于企业来说，SOA和微服务架构的结合使用自然成为了一个理想的选择：企业整体层面的问题使用SOA的理念去思考和解决，而单个软件产品或者服务按需采用微服务架构来实现，两者不是非此即彼的关系，共存在技术上貌似也没太大的难度，problem solved！

然而，由于方法论的不同，两者的区别绝不仅仅是技术层面上的，企业内部的人员组织、软件过程、质量控制、绩效考核等一整套管理机制都是与采用的架构相适应的，对于想同时适应两种架构，并把两者结合起来应用的企业来说，如何有效可持续地管理才是他们面对的真正挑战。

正如n多年前的一位大师所说，“There is no silver bullet”，就像这个世界无法用统一的物理模型解释一样，或许这就是造物主的选择，像Matrix里说的那样，造物主失败了n次后无奈的发现，只有这样架构的世界才能长久地存在下去。