架构师训练营第十周作业

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



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



如果把软件比作一个生命，那显然软件也是会经历从无到有，从小到大，从简单到复杂这样的一个历程。在这个历程过程中，软件会受两个核心因素影响：一是业务本身的发展，二是软件本身的架构设计。业务本身是决定软件能存活多久，软件能进化到多复杂。近些年随着互联网的浪潮兴起，无数公司兴起。但是真正笑到最后的往往就是那几家，那些没能活到最后的软件，是不是就意味着本身技术不行呢？其实并不然，很多软件无论开发还是设计，都非常优秀，但是这并不能保证说它就一定能笑到最后。外国已经有很多例子，雅虎，SUN公司(就是创造了java,Solari这些优秀作品的SUN公司)，诺基亚，都是这种有技术优势不能笑到最后的。总体来说，业务是一个软件能存活多久，发展到多大，多复杂的天花板。



然后就到了软件的架构设计。从我近十年的观察来看，软件的架构设计是存在阶段的，不同的阶段的架构设计重点和目标是有显著不一样的地方。比如你现在是在一个创业团队里面，那单体应用基本就可以认为是最好的架构方案，因为这个阶段的重点，是如何快速将软件产品构建出来，推向市场，抢占市场份额，此时业务不会太复杂，数据量也不大，开发团队小，单体应用最能满足快速迭代开发的要求，且相对来说，部署成本也更低，对于初创企业来说是更合适的选择。



那如果你现在是在一个成熟的平台上面做二次开发，你有充足的资源和开发团队可供使用，那微服务架构可能是个更不错的选择。因为此时业务和市场是现成的，你需要的只是理清好业务，调用已有的接口就可以满足要求了。



如果说现在业务已经很成熟了，但是苦于开拓新业务缓慢，这个时候往往就是系统耦合严重导致的。中台化，领域驱动就是很适合的策略。通过领域驱动进行业务的梳理和重构，基于中台化进行业务的沉淀和专业化，这样的大中台和小前台的架构，就可以在已有的能力上面，快速完成产品的迭代和推广。



最后借用老师的ppt,作为一个总结：