微服务 “入门易，出门难”
介绍微服务架构好处的文章比较多，最近交付的一个项目发现的缺点也比较明显，给方案设计，性能，测试，运维，问题排查，数据管理，配置管理，事务管理，研发管理都带来了不少挑战。如果使用不慎，研发成本，交付成本和运维成本都可能会大幅度上升。
自己的体会，不能简单通过技术角度看待微服务化，为了微服务而微服务潜在风险很大，不好的微服务切分会带来不必要的沟通路径，而沟通路径增加会带来更大的复杂度，这违背了微服务设计的初衷。微服务“入门容易，掌握难，出门难”。
建议的原则是业务驱动，设计保障，演进式迭代，保守治疗的方式。搞不清楚，有争议的地方先尽量不要拆，如果确实要拆，要经过业务分析后慎重设计，把真正相对独立的部分拆分出来，可以借鉴DDD的方式。拆了以后要观察微服务的接口是否稳定，针对业务需求的变更微服务的模块是否可以保持相对稳定，是否可以独立演进。
微服务的缺点
正好看了一个国外帖子，总结的不错，翻译并增加了自己的一些体会：
以下是微服务架构的缺点：
团队沟通的过载：微服务架构降低了团队管理的难度，但是确不能降低团队沟通的需求。研发人员需要确保一个服务中的更新不会破坏其它功能。我们在单体应用中也会发现类似问题，但是微服务架构的应用这个问题会更加明显。
正式文档的过载：每一个独立的运行部件需要持续维护其规格和接口文档，这些文档是其它团队使用这些部件的必要条件。
不一致性的应用：我们可以为每一个组件选择不同的技术栈。这导致了不一致的应用设计和架构，而这会在更长期的运维期间增加系统维护成本。
DevOps的复杂度：我们需要拥有一支成熟的DevOps团队去处理微服务架构的应用的复杂性。由于多个应用存在多个活动部件，这种复杂度需要有高水平的经验。
增加了资源使用：运行这些微服务架构的应用的初始投资会比较大，因为所有微服务应都需要拥有他们自己的运行容器，这也需要更多的CPU和内存。另外采用了中间件也会带啦一个比较大的基座投资。
增加了网络通信开销：分布式系统的产生的网络开销比单机应用多很多，不能简单把内部调用简单改为分布式调用，吃亏很大。微服务架构下，独立运行的组件都需要通过网络进行互相通信。这中系统需要有更加可靠和快速的网络连接。
编码和解码：这个容易理解，也会产生性能问题。
网络安全：通过网络进行通信的系统更容易产生安全缺陷。
测试：测试微服务架构的应用绝对比单体应用难很多，深有体会，集成测试过程是一场噩梦。
产品监控：监控微服务架构应用的成本会更高，很难获得合适的工具，自研的成本也很高。
其它：另外例如方案设计，研发管理，问题排查确实都有不少挑战。
Martin Fowler的观点
架构演进应该还是需要业务驱动和演进式迭代的，重新看了Martin Fowler的那篇
Microservices经典之作。再来体会一下这句话会有不同的体验：
“One reasonable argument we've heard is that you shouldn't start with a microservices architecture. Instead begin with a monolith, keep it modular, and split it into microservices once the monolith becomes a problem.”
不要一上来就以微服务架构做为起点。相反，要用一个单块系统做为起点，并保持其模块化。当这个单块系统出现了问题后，再将其分解为微服务。
微服务架构——不是免费的午餐
另外看到一篇文章《Microservices - Not A Free Lunch!》,也提出了微服务的几个潜在问题：
- 显著的运营开销
- 大量的开发运营(DevOps)技术要求
- 隐式接口
- 重复努力
- 分布式系统的复杂性
- 异步性的困难性
- 可测试挑战
参考：
