关于 分布式和微服务 的一些总结

Posted 2023-04-16

参考技术A

拿着爸妈提供的物质,见识他们没有见识过的世面,体验他们没有体验过的人生,到头来,却嫌弃他们如此笨拙。

个人觉得 分布式系统 面向的是 Ops ，更多的是考虑 系统性能和部署环境 之间的问题，通过分布式解决在没有 大型主机的部署环境 情况下， 系统性能的高可用和吞吐量 ，是个一个很早就提出来的一个概念，是由 集中式系统 过渡来的，随着计算机系统向 网络化 和 微型化 的发展日趋明显，同时 业务的发展 ，传统的 集中式 处理模式越来越不能适应人们的需求，学习成本高，大型主机贵、容错性差，扩容困难。

为了解决业务快速发展给IT系统带来的巨大挑战,从2009年开始,阿里集团启动了去IOE计划,其电商系统开始正式迈入 分布式系统时代 。

在 《分布式系统概念与设计》 一书中,对 分布式系统 做了如下定义:

分布式系统 是一个 硬件或软件组件 分布在不同的 网络计算机 上,彼此之间 仅仅 通过 消息传递 进行 通信和协调 的系统。 (硬件或软件组件,个人理解 ，硬件组件分布我们可以结合 HarmonyOS 理解，音画同步，应用跨设备流转，软总线等硬件抽象的分布式，或者可以结合RAID(独立冗余磁盘阵列）理解，可以理解为以机器为粒度的磁盘阵列，软件组件分布这里结合我们常说的微服务分布式部署，类比java Web分布式系统。)

微服务 (Microservices) 是一种 软体架构风格 ，它是以专注于 单一责任 与功能的 小型功能区块 (Small Building Blocks) 为基础，利用 模组化 的方式组合出复杂的大型应用程式， 各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯 。 微服务的起源是由 Peter Rodgers 博士于 2005 年度云端运算博览会提出的 微 Web 服务 (Micro-Web-Service) 开始， Juval Löwy 则是与他有类似的前导想法，将类别变成细粒服务 (granular services)，以作为 Microsoft 下一阶段的软体架构，其核心想法是让服务是由类似 Unix 管道 的存取方式使用，而且复杂的服务背后是使用简单 URI 来开放介面 ，任何服务，任何细粒都能被开放 (exposed)。这个设计在 HP 的实验室被实现，具有改变复杂软体系统的强大力量。 2014年， Martin Fowler 与 James Lewis 共同提出了 微服务 的概念，定义了 微服务 是由以 单一应用程式构成的小服务 ，自己拥有自己的 行程 与 轻量化处理 ，服务依业务功能设计，以 全自动的方式部署 ，与其他服务使用 HTTP API 通讯 。同时服务会使用 最小的规模 的 集中管理 (例如 Docker) 能力 ，服务可以用不同的 程序语言 与 资料库 等元件协作。

个人觉得 微服务 架构更多的是面向 dev ,更多的是考虑 编码和项目业务之间 的问题,根据 功能 把 应用拆分为服务 。解决的是 开发问题和应用复杂性 ，是在对于业务的快速发展中 单体应用 不能满足需要的时候，提出来的一个概念， 《微服务架构设计模式》 一书中对微服务架构做如下定义：

把应用程序 功能性分解 为 一组服务 的架构风格。(很直白的一句话,不需要多解释，对于大型系统而言，模块化是必不可少的，相信小伙伴也做过类似的项目， 微服务架可以看做是模块化的一种形式 ）

微服务 和 分布式 都是对 大型应用程序的扩展 ，只是 扩展方向 不同而已：

个人认为， 不属于包含关系 ，都是对于 应用扩展 的不同解决办法。一般情况下， 微服务架构的应用一般为分布式系统。但分布式系统不一定是微服务架构 。

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

摘要：从技术角度看，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次后无奈的发现，只有这样架构的世界才能长久地存在下去。