架构师训练营 - 第十周 - 总结

一、微服务

巨无霸应用系统问题

• 编译、部署困难；

• 代码分支管理困难；

• 数据库连接耗尽；

• 新增业务困难。

解决方案

纵向拆分：将一个大应用拆分为多个小应用，如果新增业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统。

横向拆分：将复用的业务拆分出来，独立部署为微服务，新增业务只需要调用这些微服务即可快速搭建一个应用系统。



微服务架构（Microservice Architecture）是一种架构概念，旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。

把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务，它可扩展单个组件而不是整个的应用程序堆栈，从而满足服务等级协议。增强可用性、服务易扩展、减少开发成本、减少服务发布对整个平台的影响。

微服务框架的需求

失效转移(Fail Over)：

对于大型网站的微服务而言，即使是很少访问的简单服务，也需要集群部署，同时微服务框架还需要支持服务提供者的失效转移机制，以实现服务高可用。

负载均衡:

对于集群部署的服务提供者，服务请求者可以使用加权轮询等手段访问，使服务提供者集群实现负载均衡。

高效的远程通信:

对于大型网站，核心服务每天的调用次数会达到数以亿计，如果没有高效的远程通信手段，服务调用可能会成为整个系统性能的瓶颈。

对应用最少侵入:

网站技术是为业务服务的，是否使用微服务需要根据业务发展规划，微服务也需要渐进式的演化，甚至会出现反复，即使用了微服务后又退回到集中式部署，微服务框架需要支持这种渐进式演化和反复。当然服务模块本身需要支持可集中式部署，也可分布式部署。

版本管理:

为了应对快速变化的需求，服务版本升级不可避免，如果仅仅是服务实现升级，那么这种升级对服务请求者而言是透明的，无需关注。但是如果服务的访问接口发生变化，就需要服务请求者和服务提供者同时升级才不会导致服务调用失败。企业应用系统可以申请停机维护，同时升级接口，而网站服务不可能中断，需要服务提供者先升级接口，并同时提供历史版本的服务供请求者调用，当请求者访问接口升级后才可以关闭历史版本服务。

微服务框架Dubbo架构



微服务框架实践

微服务架构落地

• 业务先行，先理顺业务边界和依赖，技术是手段而不是目的。

• 先有独立的模块，后有分布式的服务。

• 业务藕合严重，逻辑复杂多变的系统进行微服务重构要谨慎。

• 要搞清楚实施微服务的目的是什么，业务复用?开发边界清晰?分布式集群提升性能？



二、领域驱动设计DDD

很多项目的实际情况

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

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

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

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

领域是一个组织所做的事情以及其包含的一切，通俗地说，就是组织的业务范围和做事方式，也是软件开发的目标范围。

领域驱动设计就是从领域出发，分析领域内模型及其关系，进而设计软件系统的方法





DDD六边形架构



DDD的战略设计和战术设计

领域、子域、界限上下文、上下文映射图，这些是DDD的战略设计。

实体、值对象、聚合、CARS、事件溯源，这些是DDD战术设计。

通过战略设计，划分模块和服务的边界及依赖关系，对微服务架构的设计至关重要。



如果一个人有多年的领域经验，那么必然对领域模型设计有更深刻的认识，把握好领域模型在不断的需求变更中的演进，使系统维持更好的活力，并因此体现自己真正的价值。