架构师课程第十周 作业

一、根据微服务Dubbo的架构图，画出Dubbo进行一次微服务调用的时序图。

二、关于微服务架构（中台架构、领域驱动设计、组件设计原则），你有什么样的思考和认识？

不管什么架构设计、我觉得都要结合公司的体系、业务特点进行整合，马克思主义还需要与中国的实际情况结合才能发挥作用，否则反而害了自己。微服务架构是公司业务发展的产物，而不是因为技术厉害才出现的，所以不能算是技术驱动。微服务主要解决的是应用部署、维护、管理、迭代快等企业痛点，如果使用微服务能解决自己的问题，就是好的服务。微服务的一些特点，比如流量管理、链路追踪、安全防护、负载均衡等，也是公司实践的结果，并不一定满足所有企业的需求，可以根据自己的需求增加或者减少一部分功能，要知道，任何东西都是有利弊两面的，我们要做的是扩大有利的一面，尽量减少有弊的一面。灵活使用微服务，才能给自己带来更大的好处。当然，现在的微服务框架，已经能满足大部分公司的需求了。

领域驱动设计感觉和之前介绍的应用拆分并没有本质上的区别，只是将应用拆分从业务需求角度考虑，一切还是为了高内聚、低耦合的设计思路。领域驱动设计也不是什么新技术，或许很多公司一开始就是这样开展业务的，只不过是有人将这种思路进行了抽象，形成了一个所谓的技术、体系。很多时候也不需要刻意追求，适合的才是最好的。但从自身发展的角度来说，如果能参与到这样的实践中，对自己的发展与人生是有好处的。况且，人大部分都是喜新厌旧的，领导也是，他们出去也有了吹牛的本钱，也有了优越感，这就是现实，很多的无奈也源于此。

三、总结

本周的主要内容有：微服务介绍、dubbo微服务框架实现、Service Mesh服务网格、RPC协议原理、微服务网关、DDD、系统中台。

微服务是近些年比较热门的一个概念，也是互联网企业在发展中遇到困难、解决困难而兴起的一种技术框架。微服务主要指将单体应用进行适当拆分，各自独立开发维护管理，从而达到高效开发、快速迭代、清晰管理等目的。传统的单体应用随着业务发展，功能越来越多、模块越来越多、代码越来越多、部署越来越慢、排错越来越难，最终人们发现应用编译、部署困难、代码分支管理困难、数据库连接耗尽、新增业务困难。于是又到聪明的架构师们发挥作用的时候，将单体应用拆分成多个相互通信的小应用，这些应用称为微服务。所以微服务本质上是业务发展的需求，至于微服务中最重要的点在于怎么拆分，则需要不同的公司根据自己的业务与管理进行评估。但拆分之后的微服务，应该可以解决上述单体应用的几个问题。除了这些，微服务框架还需要实现的功能：失效转移、负载均衡、高效的远程通信、对应用最少侵入、版本管理等。

阿里开源的微服务框架Dubbo，实现了微服务的主要功能，便于开发者高效的开发微服务应用。服务提供者在启动之后会向注册中心注册自己，由注册中心管理各微服务的提供者。应用不用感知调用的服务是本地还是远程，有Dubbo客户端实现。消费者程序只要调用服务接口即可。Dubbo客户端会请求注册中心拿到服务端的信息，由于可能会有多个服务提供者，因此客户端还要使用负载均衡策略决定一个服务提供者，然后与之建立连接，请求服务。在接收到远端服务的响应之后，Dubbo客户端再将结果反序列化成对象交给应用处理。

Service Mesh服务网格旨在将微服务框架中本该有SDK实现的功能解耦到一个单独的服务中，这样可以减轻应用的负担，并且减少程序语言的依赖。服务网格一般会实现流量管理、故障注入、熔断、安全管理、协议转化、链路跟踪等功能，这样就大大减少了对应用的注入、解耦了语言之间的依赖。服务网格一般使用sidecar的方式拦截应用流量，因此需要一定的服务器资源，服务响应增加一定的延时，并且sidecar也会成为一个比较致命的故障点。因此，是否要使用服务网格，还需要公司自己评估这中间的利弊、性价比等等。

RPC协议（Remote Procedure Call），远程过程调用，是微服务框架实现远程调用的协议。主要可以使用TCP、UDP高效传输二进制或文本，为微服务之间的调用提供高效、可靠的网络通信。

基于网关的微服务架构，网关实现统一接入、安全防护、协议适配、流量管控与容错等功能。网关成为客户端与服务端之间的代理、入口，有网关决定协议转换，向服务端发出请求，可以帮助后端的多种微服务框架协议提供统一的入口、统一的接入标准。网关本身没有业务，主要职责是做各种校验与拦截，这些职责可以通过管道技术连接起来。

DDD（Domain-Driven Design），领域驱动设计，也是新兴的服务架构，从业务端考虑，将业务系统拆分为放到一个领域、子领域中，提供统一的服务，解决了功能开发混乱与调用关系复杂等问题。领域驱动设计从业务层面出发，将某一界限之内的功能模块对象集成到一个领域中，统一提供服务。

在实际项目开发过程中存在一些问题：

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

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

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

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

项目时间一长，各种困难重重，项目bug不断，需求不断延期。

领域是一个组织所做的事情以及其所包含的一切，通俗的讲，就是组织的业务范围和做事方式，也是软件开发的目标范围。领域驱动设计就是从领域出发，分析领域内模型及其关系，进而设计软件系统的方法。由于领域范围太大，所以通常将整个领域拆分成多个子领域，比如用户、商品、订单、库存、物流、发票等。如何划分子领域至关重要。在一个子领域中，会创建一个概念上的领域边界，在这个边界中，任何领域对象都只表示特定于边界内部的确切含义。这样边界便称为限界上下文。限界上下文和子领域具有一对一的关系，用来控制子领域的边界。通常限界上下文对应一个组件或者一个模块，或者一个微服务。不同的界限上下文，也即是不同的子系统或者模块之间会有各种的交互合作。DDD使用上下文映射图来设计这种交互。DDD分为战略设计与战术设计。领域、子领域、界限上下文、上下文映射图是战略设计，实体、聚合、CQRS、时间溯源是战术设计。通过战略设计，划分模块和服务的边界及依赖关系，对微服务架构的设计至关重要。

     企业系统中台其实并不是一种技术，而是服务的整合。为了提供统一的服务与规范，将一些基础的调用接口以中台的形式提供给客户调用。