架构师训练营第二期 Week 10 作业

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

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

我工作在一个小技术团队里，后端开发也就 6 人左右，人员变动也挺频繁，关于是否使用微服务架构也有过很多讨论，我一直的想法是我们人少，业务也没那么复杂，虽然需要开发很多功能，但是一个应用完全可以满足需求，就算要用微服务，我们也可以一步步来，边开发边重构，先把业务逻辑模块分开，把依赖关系搞清楚，如果真的有必要再提取出单独的服务。任何选择都是有代价的，选择了微服务就希望解耦合带来的好处能够大于更复杂系统架构带来的维护难度。不过由于时区关系，在团队里面话语权也不大，最后还是选择了服务化。但是实际上团队人少，开发任务重，没有时间将业务梳理清楚，最后强行拆分，依赖关系不清楚，开发难度也没有降低，总的感觉是得不偿失的。

关于中台，我觉得这本身不是一个技术或者一个架构，更像是一种思路。是在企业发展到非常大以后，拥有无数的前台和后台系统遇到的必然问题后顺势出现的解决问题的思路。为了给前台提供快速实现业务的能力，让开发者不需要一次又一次从无数后台服务中找出需要的部分而进行的整合。中台可以融合各种后台系统为前台开发提供整体的解决方案，方便前台的开发，从而使企业能够更快速的在不同渠道为用户提供服务。当然我们这种小团队是不可能去主动使用中台的，因为根本不需要啊。。。

领域驱动设计我们也讨论过，我当时挺感兴趣的，但我们更多只是停留在讨论阶段。我感觉推行的难度有两个。第一仍然是业务不够复杂，大家兴趣不高，第二是有学习门槛，团队里面一些没有了解的工程师不愿意花时间去学，他们宁愿去学新框架，新工具，用了以后简历上更好看一点，这个学了短时间根本看不出效果，就和学面向对象编程一样，很多人根本写不出真正的面向对象的代码，只能套用框架给的那些东西。

关于组件设计原则，和面向对象设计的理念是共通的，真正懂得面向对象设计的人，设计出来的组件不会差到哪去的。

所以归根结底，现在新语言，新框架，新技术层出不穷，但这些我觉得都属于工具，而最后落实到代码上，内功还是最重要的。只要有快速学习的能力，需要什么工具总归都可以学会的，但是平时写程序还是要提高自己的程序设计水平更重要。作为一个架构师，工具使用的差距弥补相对要容易一点，设计水平的差距应该就没法弥补了。