分布式架构模型

主流架构模型-SOA 架构和微服务架构

   

      SOA 全称（Service Oriented Architecture），中文意思为 “面向服务的架构”，他是一种设计方法，其中包含多个服务， 服务之间通过相互依赖最终提供一系列的功能。一个服务通常以独立的形式存在与操作系统进程中。各个服务之间通过网络调用

       跟 SOA 相提并论的还有一个 ESB（企业服务总线），简单 来说 ESB 就是一根管道，用来连接各个服务节点。为了集成不同系统，不同协议的服务，ESB 做了消息的转化解释 和路由工作，让不同的服务互联互通。

SOA 所解决的核心问题

1. 系统集成：站在系统的角度，解决企业系统间的通信问题，把原先散乱、无规划的系统间的网状结构，梳理成规整、可治理的系统间星形结构，这一步往往需要引入一些产品，比如 ESB、以及技术规范、服务管理规范；这一步解决的核心问题是【有序】

 

2. 系统的服务化：站在功能的角度，把业务逻辑抽象成可复用、可组装的服务，通过服务的编排实现业务的快速再生，目的：把原先固有的业务功能转变为通用的业务服务，实现业务逻辑的快速复用；这一步解决 的核心问题是【复用】

3. 业务的服务化：站在企业的角度，把企业职能抽象成可复用、可组装的服务；把原先职能化的企业架构转   变为服务化的企业架构，进一步提升企业的对外服务 能力；“前面两步都是从技术层面来解决系统调用、系 统功能复用的问题”。第三步，则是以业务驱动把一个 业务单元封装成一项服务。这一步解决的核心问题是 【高效】

 微服务架构

微服务架构其实和 SOA 架构类似,微服务是在 SOA 上做的升华，微服务架构强调的一个重点是“ 业务需要彻底的组件化和服务化 ”，原有的单个业务系统会拆分为多个可以独立开发、设计、运行的小应用。这些小应用之间通过服务完成交互和集成。

 组件表示一个可以独立更换和升级的单元，就像 PC 中的CPU、内存、显卡、硬盘一样，独立且可以更换升级而不影响其他单元。如果我们把 PC 作为组件以服务的方式构建，那么这台 PC 只需要维护主板和一些必要的外部设备。CPU、内存、硬盘都是以组件方式提供服务，PC 需要调用 CPU 做计算处理，只需要知道 CPU 这个组件的地址即可。

微服务的特征

1. 通过服务实现组件化

2. 按业务能力来划分服务和开发团队

3. 去中心化

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

SOA 和微服务架构的差别

1. 微服务不再强调传统 SOA 架构里面比较重的 ESB 企业服务总线，同时 SOA 的思想进入到单个业务系统内部实现真正的组件化

2. Docker 容器技术的出现，为微服务提供了更便利的条件，比如更小的部署单元，每个服务可以通过类似 Node或者 Spring Boot 等技术跑在自己的进程中。

3. 还有一个点大家应该可以分析出来，SOA 注重的是系 统集成方面，而微服务关注的是完全分离

领域驱动设计及业务驱动划分

领域驱动设计的概念

领域驱动设计（DDD,Domain-Driven Design），软件开发不是一蹴而就的事情，我们不可能在不了解产品（或行业领域）的前提下进行软件开发，在开发前，通常需要进行大量的业务知识梳理，然后才到软件设计的层面，最后才是开发。而在业务知识梳理的过程中，我们必然会形成某

个领域知识，根据领域知识来一步步驱动软件设计，就是领域驱动设计的基本概念

为什么需要 DDD

业务初期，功能大都非常简单，普通的 CRUD 就能满足，此时系统是清晰的。随着产品不断迭代和演化，业务逻辑变得越来越复杂，我们的系统也越来越冗杂。各个模块之间彼此关联，甚至到后期连作者都很难说清模块的具体功能意图是啥。导致在修改一个功能时，要追溯到这个功能需要的修改点就需要很长时间，更别提修改带来的不可预知的影响面。

       领域驱动设计其实我们可以简单认为是一种指导思想，是一种软件开发方法，通过 DDD 可以将系统解构更加合理，最终满足高内聚低耦合的本质。在我的观点来看，有点类似数据库的三范式，我们开始在学的时候并不太理解，当有足够的设计经验以后慢慢发现三范式带来的好处。同时 我们也并不一定需要严格按照这三范式去进行实践，有些情况下是可以灵活调整。