SOA架构和MSA架构之间的关系

二、分布式架构：面向服务架构（SOA）

1、服务与SOA

2、SOA战略

3、SOA的两大基石：RPC和MQ

三、分布式架构：微服务架构（MSA）

什么是微服务

微服务的特点 

微服务的优点

微服务的缺点

四、SOA架构和微服务架构的区别和联系

SOA架构特点：

微服务架构特点：

主要区别：

典型的企业级应用系统或者互联网应用系统一般都是通过Web提供一组业务服务能力。这类系统包括：提供给用户操作的、运行于浏览器中、具有UI的业务逻辑展示和输入部分，运行于服务器端、用后端编程语言构建的业务逻辑处理部分，以及用于存储业务数据的关系数据库或其他类型的存储软件。

根据软件系统在运行期的表现风格和部署结构，我们可以粗略地将其划分为两大类：

• 整个系统的所有功能单元，整体部署到同一个进程（所有代码可以打包成1个或多个文件），我们可以称之为“单体架构”（Monolithic Architecture）；
• 整个系统的功能单元分散到不同的进程，然后由多个进程共同提供不同的业务能力，我们称之为“分布式架构”（Distributed Architecture）；

再结合软件系统在整个生命周期的特点，我们可以进一步区分不同的架构风格。

对于单体架构，我们根据设计期和开发实现期的不同模式和划分结构，可以分为：

• 简单单体结构：代码层面没有拆分，所有的业务逻辑都在一个项目（project）里打包成一个二进制的编译后文件，通过这个文件进行部署，并提供业务能力
• MVC模式：系统内每个模块的功能组件按照不同的职责划分为模型（Model）、视图（View）、控制器（Controller）等角色，并以此来组织研发实现工作
• 前后端分离模式：将前后端代码耦合的设计改为前端逻辑和后端逻辑独立编写实现的处理模式
• 组件模式：系统的每一个模块拆分为一个子项目（subproject），每个模块独立编译打包成一个组件，然后所有需要的组件一起再部署到同一个容器里；
• 类库模式：A系统需要复用B系统的某些功能，这时可以直接把B系统的某些组件作为依赖库，打包到A系统来使用

对于分布式架构，我们根据设计期的架构思想和运行期的不同结构，可以分为：

• 面向服务架构（Service Oriented Architecture，SOA）：以业务服务的角度和服务总线的方式（一般是WebService与ESB）考虑系统架构和企业IT治理
• 分布式服务架构（Distributed Service Architecture，DSA）：基于去中心化的分布式服务框架与技术，考虑系统架构和服务治理
• 微服务架构（MicroServices Architecture，MSA）：微服务架构可以看做是面向服务架构和分布式服务架构的拓展，使用更细粒度的服务（所以叫微服务）和一组设计准则来考虑大规模的复杂系统架构设计。

也有人把如上的各个架构风格总结为4个大的架构发展阶段：

一、传统架构：简单单体模式

简单单体模式是最简单的架构风格，所有的代码全都在一个项目中。这样研发团队的任何一个人都可以随时修改任意的一段代码，或者增加一些新的代码。开发人员也可以只在自己的电脑上就可以随时开发、调试、测试整个系统的功能。也不需要额外的一些依赖条件和准备步骤，我们就可以直接编译打包整个系统代码，创建一个可以发布的二进制版本。这种方式对于一个新团队的创立初期，需要迅速开始从0到1，抓住时机实现产品最短时间推向市场，可以省去各种额外的设计，直接上手干活，争取了时间，因而是非常有意义的。

但是这种简单单体模式对于一个系统后期的稳定发展还是有很多坏处的：

• 简单单体模式的系统存在代码严重耦合的问题：代码之间的相互引用，导致了系统内的对象之间相互依赖，关系混乱。修改其中的一处代码，可能会引发一大片代码的变化。对于经常需要修改维护的系统，很显然会引发很大的问题。
• 简单单体模式的系统变更对部署影响大：系统作为一个单体部署，每次发布的部署单元就是一个新版本的整个系统，系统内的任何业务逻辑调整都会导致整个系统的重新打包，部署、停机、再重启，进而导致了系统的停机发布时间较长。每次发布上线都是生产系统的重大变更，这种部署模式大大提升了系统风险，降低了系统的可用性。
• 简单单体模式的系统影响开发效率
• 简单单体模式打包后的部署结构可能过于庞大：部署结构过于庞大，导致业务系统启动很慢，进而也会影响系统的可用性。
• 扩展性受限：如果任何一个业务存在性能问题，那么都需要考虑多部署几个完整的实例的集群，或者再加上负载均衡设备，才能保证整个系统的性能可以支撑用户的使用。

二、分布式架构：面向服务架构（SOA）

1、服务与SOA

面向服务架构（SOA）是一种建设企业IT生态系统的架构指导思想。SOA的关注点是服务。服务最基本的业务功能单元，由平台中立性的接口契约来定义。通过将业务系统服务化，可以将不同模块解耦，各种异构系统间可以轻松实现服务调用、消息交换和资源共享。

各个系统的业务拆解为不同粒度和层次的模块和服务，服务可以组装到更大的粒度，不同来源的服务可以编排到同一个处理流程，实现非常复杂的集成场景和更加丰富的业务能力。而且系统的复用可以从以前的代码级的粒度扩展到业务服务的粒度，能够快速的对业务和集成需求的变更。SOA从更高的层次对真个系统机型了统一的设计和处理，对消息处理和服务调用进行监控，优化资源和配置，降低系统复杂度和综合成本，为业务流程梳理和优化提供技术支撑。

在SOA体系下，应用软件被划分为具有不同功能的服务单元，并通过标准的软件接口把这些服务联系起来，以SOA架构实现的企业应用可以更灵活快速地响应企业业务变化，实现新旧软件资产的整合和复用，降低软件整体拥有成本。

2、SOA战略

SOA的实施对整个IT生态环境都有重要的影响，作为一种重大的IT变革和技术决策，必然要自上而下的进行。必须获得管理层的支持，由技术决策层面直接推动，并和技术部门、相关业务部门一起，根据目前各个IT业务系统的现状，统一规划SOA战略和分阶段目标，制定可行方案与计划步骤，逐步推进实施。

3、SOA的两大基石：RPC和MQ

SOA关注于系统的服务化，不同系统服务间的相互通信就成为了一个重要的话题。并且随着RPC和MQ技术的发展，这两种技术逐渐成为SOA的两大基石，也是分布式技术体系里的重要基础设施。

RPC

RPC，即 Remote Procedure Call（远程过程调用），是一个计算机通信协议。 该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。说得通俗一点就是：A计算机提供一个服务，B计算机可以像调用本地服务那样调用A计算机的服务。

RPC的调用关系里，我们把提供具体的调用方法的系统叫服务提供者（Provider），调用服务的系统称为服务消费者（Consumer）。把对象转换为以便于网络传输的二进制或文本数据的过程，叫做序列化（Serialization）；二进制或文本数据再还原为对象的过程，叫做反序列化（Deserialization）。 我们可以看到，典型的RPC处理机制包括两部分：

• 通信协议，可以是基于tcp的，也可以是基于http的。
• 数据格式，一般是一套序列化+反序列化机制。

MQ

MQ（Message Queue，消息队列） 异步的远程调用，如果能同时存在很多个请求，该如何处理呢？进一步地，由于不能立即拿到处理结果，假若需要考虑失败策略，重试次数等，应该怎么设计呢？ 如果有N个不同系统相互之间都有RPC调用，这时候整个系统环境就是一个很大的网状结构，依赖关系有N*(N-1)/2个。任何一个系统出问题，都会影响剩下N-1个系统，怎么降低这种耦合呢？

基于这些问题，我们发展出来了消息队列（MQ）技术，所有的处理请求先作为一个消息发送到MQ（一般我们叫做broker），接着处理消息的系统从MQ拿到消息并进行处理。这样就实现了各个系统间的解耦，同时可以把失败策略、重试等作为一个机制，对各个应用透明，直接在MQ与各调用方的应用接口层面实现即可。

一般来说，我们把发送消息的系统称为消息生产者（message producer），接受处理消息的系统称为消息消费者（message consumer）。

三、分布式架构：微服务架构（MSA）

什么是微服务

The term "Microservice Architecture" has sprung up over the last few years to describe a particular way of designing software applications as suites of independently deployable services. While there is no precise definition of this architectural style, there are certain common characteristics around organization around business capability, automated deployment, intelligence in the endpoints, and decentralized control of languages and data. 

通过Martin Flowler的这段微服务描述，可以抽象出以下几个关键点：

• 由一些独立的服务共同组成应用系统
• 每个服务单独布署、独立跑在自己的进程中
• 每个服务都是独立的业务
• 分布式管理

通过几个关键点可以看出微服务重在独立布署和独立业务，而所谓的微服务，并不是越小越好，而是通过团队规模和业务复杂度由粗到细的划分过程，所遵循的原则是松耦合和高内聚。

微服务的特点 

• 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责
• 微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但“五脏俱全”
• 面向服务：面向服务是说每个服务都要对外暴露服务接口API。并不关心服务的技术实现，做到与平台和语言无关，也不限定用什么技术实现，只要提供Rest的接口即可
• 自治：自治是说服务间互相独立，互不干扰
• 团队独立：每个服务都是一个独立的开发团队，人数不能过多
• 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉
• 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不用再为PC、移动段开发不同接口
• 数据库分离：每个服务都使用自己的数据源
• 部署独立：服务间虽然有调用，但要做到服务重启不影响其它服务。有利于持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，易维护

微服务的优点

1.每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。微服务架构模式给采用单体式编码方式很难实现的功能提供了模块化的解决方案，由此，单个服务很容易开发、理解和维护。

2.微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。

3.微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的，可以加快部署速度。UI团队可以采用AB测试，快速的部署变化。微服务架构模式使得持续化部署成为可能

4.微服务能使用不同的语言开发。

5.微服务易于被一个开发人员理解，修改和维护，这样小团队能够更关注自己的工作成果。无需通过合作才能体现价值。

6.微服务允许你利用融合最新技术。

7.微服务只是业务逻辑的代码，不会和HTML,CSS 或其他界面组件混合。

微服务的缺点

1.微服务架构可能带来过多的操作（服务拆分）

2.需要DevOps技巧 

3.可能双倍的努力。

4.分布式系统可能复杂难以管理。开发者需要在RPC或者消息传递之间选择并完成进程间通讯机制。更甚于，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。当然这并不是什么难事，但相对于单体式应用中通过语言层级的方法或者进程调用，微服务下这种技术显得更复杂一些。

5.因为分布部署跟踪问题难。

6.当服务数量增加，管理复杂性增加

7.分区的数据库架构。商业交易中同时给多个业务分主体更新消息很普遍。这种交易对于单体式应用来说很容易，因为只有一个数据库。在微服务架构应用中，需要更新不同服务所使用的不同的数据库。使用分布式交易并不一定是好的选择，不仅仅是因为CAP理论，还因为今天高扩展性的NoSQL数据库和消息传递中间件并不支持这一需求。最终你不得不使用一个最终一致性的方法，从而对开发者提出了更高的要求和挑战。

四、SOA架构和微服务架构的区别和联系

SOA架构特点：

• 系统集成：站在系统的角度，解决企业系统间的通信问题，把原先散乱、无规划的系统间的网状结构，梳理成 规整、可治理的系统间星形结构，这一步往往需要引入 一些产品，比如 ESB[企业服务总线(Enterprise Service Bus)]、以及技术规范、服务管理规范； 这一步解决的核心问题是【有序】
• 系统的服务化：站在功能的角度，把业务逻辑抽象成 可复用、可组装的服务，通过服务的编排实现业务的 快速再生，目的：把原先固有的业务功能转变为通用 的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是【复用】
• 业务的服务化：站在企业的角度，把企业职能抽象成 可复用、可组装的服务；把原先职能化的企业架构转变为服务化的企业架构，进一步提升企业的对外服务能力；
• “前面两步都是从技术层面来解决系统调用、系统功能复用的问题”。第三步，则是以业务驱动把一个业务单元封装成一项服务。这一步解决的核心问题是【高效】

微服务架构特点：

1.通过服务实现组件化：开发者不再需要协调其它服务部署对本服务的影响。
2.按业务能力来划分服务和开发团队：开发者可以自由选择开发技术，提供 API 服务
3.去中心化

• 每个微服务有自己私有的数据库持久化业务数据
• 每个微服务只能访问自己的数据库，而不能访问其它服务的数据库
• 某些业务场景下，需要在一个事务中更新多个数据库。这种情况也不能直接访问其它微服务的数据库，而是通过对于微服务进行操作。
• 数据的去中心化，进一步降低了微服务之间的耦合度，不同服务可以采用不同的数据库技术（SQL、NoSQL等）。在复杂的业务场景下，如果包含多个微服务，通常在客户端或者中间层（网关）处理。

4.基础设施自动化（devops、自动化部署）

传统的Java EE部署架构，通过展现层打包WARs，业务层划分到JARs最后部署为EAR一个大包，而微服务则打开了这个黑盒子，把应用拆分成为一个一个的单个服务，应用Docker技术，不依赖任何服务器和数据模型，是一个全栈应用，可以通过自动化方式独立部署，每个服务运行在自己的进程中，通过轻量的通讯机制联系，经常是基于HTTP资源API，这些服务基于业务能力构建，能实现集中化管理（因为服务太多啦，不集中管理就无法DevOps啦）。
 

主要区别：

---------------------
作者：devillyd2018
来源：CSDN
原文：https://blog.csdn.net/devillyd2018/article/details/118032720
版权声明：本文为作者原创文章，转载请附上博文链接！
内容解析By： CSDN,CNBLOG博客文章一键转载插件