架构师训练营 1 期 -- 第十周作业

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





答：Dubbo进行一次微服务调用时序图如下：



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

答：我们公司之前有一套系统，本来是做设备监控的，后来随着业务的发展，功能原来越多，使得整个系统变得庞大而臃肿，凸显的问题包括：

• 开发效率低下，每次开发新功能时，找文件，找方法比较困难，启动项目时间长。

• 模块职责不清晰，项目经过几代人开发，有的功能模块重复开发，有些代码本应该放在一个模块中的，结果放到了好几个模块中。

• 项目运行效率低下，随着数据的增多，有些数据库聚合查询严重影响性能，之前有一个页面打开需要12秒，经过优化后，还需要5秒。

• 项目维护困难，项目大概几百兆，每次发版本，需要时间也比较长。项目一大堆日志，需要经过一些处理才能找到相关日志，

后来决定对这个项目进行重构，把项目分成几个大的模块，监控中心，数据中心，搜索中心(一期没做，基于ES)，用户中心，后台服务(主要提供一下API)，前端系统。

以这样的粒度进行拆分，也是基于模块复用的考虑，因为有很多不同的应用都有用户注册功能，所以我们使用Oauth2.0开发了用户中心。监控中心单独拆分出来，方便各种客户的接入监控系统。数据中心表不是太多，所以放在一个模块中。提供一个统一的后台API服务，客户以及前端都可以调用。

在技术选型时，我们决定使用微服务框架，在Spring Cloud和Dubbo之间进行选择，最后还是选择了Spring Cloud，主要是基于以下考虑：

Spring Cloud是一站式解决方案，提供了更多的解决方案，比如统一配置中心，熔断，降级，调用链追踪，这些方案都有了，在Dubbo中，这些可能需要借助第三方解决方案。

Dubbo的优势在于他的性能，它有自己的协议，基于RPC调用，而Spring Cloud是基于restful API的，另外它的监管治理做的比较好，比如能收集API调用次数等等。

但是不管怎么说，两个应该都算好框架，都能解决我们的问题。而对于学习成本而言，两个差不多，我们之前都没接触过，所以都是从头开始。

在我们上微服务之前，也没有学习过DDD，通过这一周的学习，感觉也有一些设计思想和老师说的是吻合的，比如业务先行，复用发布等同远些，共同封闭原则，共同复用原则，稳定依赖原则，无循环依赖原则等。另外还有就是老师说的，多对业务做梳理，多对问题做分析，多讨论，这对设计出一个好的微服务系统来说，是很重要的。

另外还有一点是，上了微服务，自动化运维也是比较重要的，否则运维这块会比较辛苦。我们采用了K8S，实现了自动化部署，整体看起来，还算比较成功，系统比较稳定，对于后来的功能扩展也比较容易一些，同时也得到了老板的认可，就是今年疫情原因，大家都没加薪 ^..^