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

用户头像
曾彪彪
关注
发布于: 2020 年 11 月 29 日

根据微服务框架 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,实现了自动化部署,整体看起来,还算比较成功,系统比较稳定,对于后来的功能扩展也比较容易一些,同时也得到了老板的认可,就是今年疫情原因,大家都没加薪 ^..^



用户头像

曾彪彪

关注

还未添加个人签名 2019.03.23 加入

还未添加个人简介

评论

发布
暂无评论
架构师训练营 1 期 -- 第十周作业