最近刚好在接触不少后端架构设计方面的需求，对不少方案都进行了深入的了解。原本只是在后端八股文浅学的一些微服务理解，在现在看来也确实多了很多不同看法。
解耦合
以前看八股文的时候，多是关注微服务对性能上的一些影响。但是当自己真正去为团队设计架构的时候，才会发现最需要考虑的其实是对项目的学习成本（或许是因为都只是为学校里的团队设计架构，而没有一个真实带领一个大厂的团队的经历吧）。新成员的基础通常都是无法直接上手开发的，让其去了解整个系统是怎么运作的难度颇高。但如果是微服务就可以减轻这方面的负担。 并且，对系统解耦合过后，不同团队的分工协作也可以更加明确。都说一个程序员其实 80%可能都是在开会，因为需要频繁与团队里负责其他关联模块的同学去进行沟通，但是微服务架构就在一定程度上减少了这种沟通成本。 当然，解耦合为不同的子系统也可以，这些子系统不需要互相通信，直接与前端对接。只是说通常来说，不同系统间会有一些互相通信的需求。
问题追溯
如果说是一个单体部署的架构的话，服务出现问题时，通常需要一定时间才能找出是哪一个部分出现了问题。但微服务间是互相依赖的，一旦有一个出现问题，Debug 的时候很容易通过其中的依赖关系去找到对应出错的模块，从而快速解决问题。