架构师训练营第十周作业

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

如下图：



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



谈谈我在这几年工作中对于微服务的一些认识。我一直从事银行IT的开发工作，经历了银行系统从大集中到SOA再到现在要搞微服务。架构发展的趋势与课堂上李老师讲的有些相似。刚开始银行是从IBM买了一套核心系统，银行的所有业务都在上面开发：存款、转账、贷款、中间业务、网银后台等等。随着体量增加和业务发展，在一个核心系统的业务开发的复杂度越来越高，系统的垂直扩展也无法给性能带来更大的提升。银行系统开始根据业务进行拆分，把非核心账务的业务拆分给新的系统。银行系统架构经历了大的变革，从大集中到SOA架构，每个大的业务都用一个系统来实现，提供服务供其他服务调用。

近年来，随着微服务的概念在技术权的兴起，银行也在尝试向微服务转变。但是如果做微服务设计，服务拆分的边界怎么界定，我认为还做得不好，或者是业界还没有一套好的银行业务系统微服务架构设计的最佳实践。比如，以前一套贷款系统，所有功能就自己实现，然后暴露服务接口给其他业务系统调用。曾经尝试做微服务架构的改造，只是把各个子模块微服务化独立出来。最后反而增加了模块间通信交互的成本。独立出来的微服务也没有太多的供其他系统复用。架构变复杂了，给业务带来的收益却又不大，为了微服务而微服务。

如何定义业务边界，如何让微服务架构能应对业务增长带来的问题，我认为这应该是设计微服务架构最先考虑的。