微服务

单体架构

1、所有的功能集成在一个项目工程中。

2、所有的功能打在一个 war 包部署到服务器。

3、通过部署应用集群和数据库集群来提高系统的性能。

优点：

1、项目架构简单，前期开发成本低，周期短，小型项目的首选。

2、开发效率高，模块之间交互采用本地方法调用。

3、容易部署，运维成本小，直接打包到 web 容器即可运行。

4、容易测试，无依赖，在本地就可以启动调试完整的系统。

缺点：

1. 编译、部署困难

2. 代码分支管理困难：复用的代码模块由多个团队共同维护修改，代码 merge 总会发生冲突。每次发布都半夜。

3. 数据库连接耗尽

4. 巨型的应用、大量的访问

5. 新增业务困难，无法针对业务按需伸缩

解决方案就是拆分，将模块独立部署，降低系统耦合性：

• 纵向拆分：拆成多个小应用，新增业务独立

• 横向拆分：复用的业务拆分出来，独立部署为微服务，新增业务只需调用这些就可以。

垂直架构

特点：

1、按业务垂直拆分成一个一个的单体系统，此架构也称为垂直架构。

2、系统与系统之间的存在数据冗余，耦合性较大，如上图中三个项目都存在客户信息。

3、系统之间的接口多为实现数据同步，如上图中三个项目要同步客户信息。

优点：

1、通过垂直拆分，每个子系统变成小型系统，功能简单，前期开发成本低，周期短。

2、每个子系统可按需伸缩。

3、每个子系统可采用不同的技术。

缺点：

1、子系统之间存在数据冗余、功能冗余，耦合性高。

2、按需伸缩粒度不够，对同一个子系统中的不同的业务无法实现，比如订单管理和用户管理。

微服务架构

特点：

1、服务层按业务拆分为一个一个的微服务。

2、微服务的职责单一。

3、微服务之间采用 RESTful、RPC 等轻量级协议传输。

4、有利于采用前后端分离架构。

优点：

1、服务拆分粒度更细，有利于资源重复利用，提高开发效率。

2、可以更加精准的制定每个服务的优化方案，按需伸缩。

3、适用于互联网时代，产品迭代周期更短。

缺点：

1、开发的复杂性增加，因为一个业务流程需要多个微服务通过网络交互来完成。

2、微服务过多，服务治理成本高，不利于系统维护。

3、业务逻辑+公共库+开发框架 都耦合在一起。

serverMesh 架构（微服务 2.0）

把非业务相关封装成 sideCar（边车）的形式以单独的进程（prod）单独部署，可以在同一台机器上也可以不在同一台机器上，而获得业务与技术的进一步解耦，同时让业务开发不再关注技术细节。

以及后来 Bilgin Ibryam 提出的 mecha（多运行时）架构让业务和技术更进一步解耦成为一种可能。

通过 mecha 的 把传统的中间件这样的类库或组件，转移到平台级别，通过进程外的这种模型， 以多运行时的方式对应用提供扩展，而我们的 应用只关注业务本身，只需要编写业务逻辑就可以了，获得各种分布式需要的超能力

1. 微逻辑

2. mecha 组件（机甲）

• 开箱即用

• 可配置能力

• 声明式

• openAPI

优点：

业务逻辑和越来越多的分布式系统问题之间的松耦合，同时解决了 sidecar 过多维护困难的问题。

缺点：

进程间通信- 部署在同一台主机，获得低延迟

复杂度 -混合式开发技能

基于网关的微服务架构

领域驱动设计（DDD）

DDD 强调业务架构和系统架构的绑定，以及和技术架构保持“低表示差异“，减少翻译的过程，系统架构随着业务架构的变化而变化，软件能最大程度地体现业务和设计决策。

为什么需要 DDD？

很多项目面临的情况：

1. 用户或者产品经理的需求零零散散，不断变更。

2. 工程师在各处代码中寻找可以实现这些需求变更过的代码，修修补补。

3. 软件只有需求分析，没有真正的设计，系统没有一个同一个的领域模型维持其内在的逻辑一致性。

4. 功能性并不是按照领域模型内在的逻辑设计，而是按照各色人等自己的主观想象设计。

5. 项目时间一长，各种困难重重，需求不断延期，线上 bug 不断，管理者考虑是不是要推到重来，二程序员则考虑是不是要跑路。

由前面的认知，微服务解决了或提升了应用的吞吐量和可用性，并没有解决日益正在的开发问题和应用复杂性。

领域：是一个组织所做的事情以及其保护的一切，通俗地说，就是组织的业务范围和做事方式，也是软件开发的目标范围。领域驱动设计就是从领域出发，分析领域内模型及其关系，进而设计软件系统的方法。领域是相对于系统而言的，系统是一种解决方案，利用就是系统要解决的现实问题所属的空间，即是问题空间，这个空间主要由业务知识或活动组成。

驱动：

• 把关注点放在核心域及核心域的领域逻辑上

• 基于建模进行复杂设计

• 通过技术专家和领域专家共同协作迭代式的探索模型，切入问题的核心概念

• 将实现与核心业务概念模型紧密地联系在一起，让应用能清晰地体现业务和设计意图，让系统容易随着业务的变化容易演进

设计：是一种“有目的的创作行为。软件设计是根据需求分析阶段确定的功能来设计软件系统的整体结构、划分功能模块、确定每个模块的实现算法以及编写具体的代码，最后形成软件的具体设计方案。设计属于解决方案的空间

领域模型应该是架构中立的。 有时候、我们过于强调架构而忽略了 DDD 建模的重要性。架构并非一成不变。此时我们应该正确地处理优先级，将重点放在领域模型上，因为领域模型将产生更多的业务价值，并且更具有持久性。

战略设计：划分领域、子域，上下文等。

战术设计：

六边形架构（端口/适配器架构）

业务逻辑除以中心位置，技术细节位于边缘，通过依赖倒置实现业务不依赖于技术；另外，业务层要”厚“，技术层要”薄“；

整洁架构

设计原则：

• 关注点分离

• 依赖倒置-API、SPI 等实现

• CQRS

• 事件溯源

• 聚合

思考

要想脱颖而出，仅仅靠学习是不够的。靠学习只能维持不被淘汰，要找到工作中问题的核心，用学习+（思考）创新的方式找到切实可行的解决方案，通过学习常见的套路，加强自己的认知水平，糅合锤炼成非常规的解决方案，去真正解决现实中的问题，从而达到学以致用，成就自我的高度。

1、 通过不断学习，提高认知力

2、通过总结和思考，升华自己的知识体系，分类整理，要寻根问底。

3、通过分享和传授（也是最好的学习方法），提高自己的影响力，巩固自己的学习成果。

4、通过实践，解决实际问题，验证自己的思路，公司发展的需要，体现自己的价值。

5、水滴穿石非一日之功，必须反复锤炼才能去杂成刚。