架构师训练营第十周作业

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



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

微服务架构很多情况下并非一开始就设计好的，而是根据业务需要演化而来的。以最近的机电运维项目为例。

项目最初需求：实现变电站机电设备的全生命周期管理，包括设备运行状态监测、变电所视频监控、日常运维、备件管理。根据业务需求，项目最初实现为单体架构。

随着甲方业务的不断拓展，甲方的机电运维对象从变电站扩展到了电信机房、隧道、楼宇等，从而需要建立多个运维子项目(变电站运维系统、电信机房运维系统、隧道运维系统、智慧楼宇运维系统)，用户需要在多个子系统之间单点登录，同时备件管理系统要同时为多个运维子系统服务。

随着业务需求的变更，我们对机电运维系统的认识也在不断发展，从单一的产品逐步发展为产品线，系统架构也需要从单体架构演化为微服务架构。我们将多个子系统中可复用的部分抽离成服务，形成业务中台，根据领域驱动设计和组件设计的的思想，我们经过分析，最终形成了以下业务中台：

用户中台：统一用户账号体系，多个系统之间通过Oauth2.0实现单点登录。

流媒体处理服务：专门提供视频转码服务，以实现监控视频在Web页面的无插件播放。

备件管理服务：实现备件的统一管理，为各个运维子系统提供备件领用、归还服务。

物联网平台：将设备数据采集、上报和监测功能独立成物联网，实现所有子系统设备的统一管理，为子系统提供设备的实时数据，各子系统无需单独接入设备。



认识：

架构永远是业务驱动而非技术驱动，什么样的业务需要决定了什么样的架构，架构师要用合适的架构解决现实问题。现实中经常碰到为了微服务而微服务的架构师，盲目追求技术的先进性和流行性，而不考虑需求本身，明明一个单体架构就可以解决的项目，非要做成微服务，独立出的微服务也没有复用性，把简单的问题复杂化，白白增加了开发和运维成本。没有最好的架构，只有合适的架构！