为什么选择微服务
由于多人共同维护一个项目实在是太麻烦，团队打算引用微服务技术栈，将代码按业务拆分为多项不同微服务单独维护，促使这样做的原因有以下几点：
- 提高开发速度：单人或几个人维护一个微服务可以有效避免开发中的代码冲突问题，另外小团队的代码更容易理解，修改和维护。
- 技术管理较为自由：你可以自由选择最新的技术和轮子。
用代码堆彻的沙堡之城
在微服务架构完后，业务开发人员开始填充代码，这个阶段下，新需求能在微服务上写的都会在微服务上完成，老的项目中的功能点也逐步的迁移到新项目中，由于存在多个服务频繁调用的基础服务，又新建了基础服务中台和数据中台，由于各个服务直接关联不大，这一阶段还算顺利且愉快。
痛点
组织
自由且缺乏管理会产生乱象，在人为因素的驱动下做出技术决策时，我们很快就会遇到了问题。新团队的组织和流程很难与现有的团队并行不悖。由于特性是独立开发的，很快就出现了知识分化。微服务内部的东西没法共享，而跨栈代码审查的缺失让我们觉得失去了 ownership。
隔离
在上面的架构中，微服务 Customer Success 并非完全隔离。从单体到微服务存在后端到后端的通信，反之亦然。这并不完全是坏事），但这还是会降低性能，并在两个服务之间创建依赖关系。从长远来看，这还意味着更复杂的机制，如 circuit breakers 和优雅的服务降级（为保证正常运行时间和可用性）。
由于后端数据库是共享的。在数据库内部修改共享表的字段需要对微服务和单体进行同步修改。这也是由糟糕的领域隔离所导致的。
协作
不得不承认，当每个服务发展到一定程度，其与其他服务的耦合度是非常高的，而且每个服务可以独立部署导致需要同步部署依赖服务，我们内部每个微服务是通过版本号去迭代的，这就需要服务1如果有重大升级，那么其依赖服务1的所有服务都需要升级版本并同步部署一次。
解决
分离数据库
在项目发展到一定程度后，分离数据库就成了一种必然选择。
搭建dev开发环境
在公司内部搭建本地的dev开发环境，环境由团队共同维护，可以有效解决不同服务间的调用及调试问题。
小结
本文不是要批评微服务，目前微服务架构在团队中还是利大于弊的存在，但是我们也要正视他存在的问题，并逐步的去解决他。