微服务架构的缺点
介绍微服务架构好处的文章比较多，最近交付的一个项目发现的缺点确实也比较明显，给方案设计，性能，测试，运维，问题排查，数据管理，配置管理，事务管理，研发管理都带来了不少挑战。如果使用不慎，研发成本，交付成本和运维成本都可能会有大幅度上升。
正好看了一个国外帖子，总结的不错，翻译并增加了自己的一些体会：
以下是微服务架构的缺点：
-
团队沟通的过载：微服务架构降低了团队管理的难度，但是确不能降低团队沟通的需求。研发人员需要确保一个服务中的更新不会破坏其它功能。我们在单体应用中也会发现类似问题，但是微服务架构的应用这个问题会更加明显。
-
正式文档的过载：每一个独立的运行部件需要持续维护其规格和接口文档，这些文档是其它团队使用这些部件的必要条件。
-
不一致性的应用：我们可以为每一个组件选择不同的技术栈。这导致了不一致的应用设计和架构，而这会在更长期的运维期间增加系统维护成本。
-
DevOps的复杂度：我们需要拥有一支成熟的DevOps团队去处理微服务架构的应用的复杂性。由于多个应用存在多个活动部件，这种复杂度需要有高水平的经验。
-
增加了资源使用：运行这些微服务架构的应用的初始投资会比较大，因为所有微服务应都需要拥有他们自己的运行容器，这也需要更多的CPU和内存。另外采用了中间件也会带啦一个比较大的基座投资。
-
增加了网络通信开销：分布式系统的产生的网络开销比单机应用多很多，不能简单把内部调用简单改为分布式调用，吃亏很大。微服务架构下，独立运行的组件都需要通过网络进行互相通信。这中系统需要有更加可靠和快速的网络连接。
-
编码和解码：这个容易理解，也会产生性能问题。
-
网络安全：通过网络进行通信的系统更容易产生安全缺陷。
-
测试：测试微服务架构的应用绝对比单体应用难很多，深有体会，集成测试过程是一场噩梦。
-
产品监控：监控微服务架构应用的成本会更高，很难获得合适的工具，自研的成本也很高。
-
其它：另外例如方案设计，研发管理，问题排查确实都有不少挑战。
架构演进应该还是需要业务驱动和演进式迭代的，重新看了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.”
不要一上来就以微服务架构做为起点。相反，要用一个单块系统做为起点，并保持其模块化。当这个单块系统出现了问题后，再将其分解为微服务。
