微服务架构的运维问题，主要是相对于单体架构来说的。因为实施微服务架构后，整个系统的模块一下子比原来多了很多，模块变多后，部署和维护的工作量都会变大。所以，解决运维难的问题，可以先从“自动化”的角度来解决。

更进一步，如果希望更好地发挥微服务架构的优势，规避缺点，则建议准备一个可靠的基础设施，包含自动构建、自动部署、日志中心、健康检查、性能监控等功能。

否则，很有可能会因为微服务架构的缺点导致我们的团队丧失对微服务架构的信心，从而回到单体架构的老路上去。工欲善其事，必先利其器，这一点真的很重要。

    何谓微服务架构的简单模式？相对于大型互联网平台动辄几万并发的访问量，或者每天多次的在线版本发布，绝大多数企业和项目并没有这样的需求。他们关注的是如何更好地提高开发效率，如何更快地实现新需求，如何更便利地运维，等等。

微服务架构的简单模式就是可以满足以上需求的软件架构方案。相对于“完美”的微服务架构方案，微服务架构简单模式可以暂且不用关注保障数据一致性的分布式事务技术、方便程序包在环境间（开发、测试、生产）迁移的配置中心组件、监控 API 调用情况的调用链组件、避免系统超载的断路器组件、方便 API 管理和测试的 API 文档框架、Zookeeper、Redis，以及各种 MQ。只需要关注常常谈到的 注册中心、服务发现、负载均衡 和 服务网关 即可。

近年来，Spring Cloud 俨然已经成为微服务开发的主流技术栈，在国内开发者社区非常火爆。

基于我长期以来在一线互联网公司（携程，拍拍贷等）开展微服务架构的实践经验以及平时对 Spring Cloud 的调研，我认为 Spring Cloud 技术栈中的一部分组件离生产级开发尚有一定距离。

比方说 Spring Cloud Config 和 Spring Cloud Sleuth 都是 Pivotal 自研产品，尚未得到大规模企业级生产应用，很多企业级特性缺失，另外 Spring Cloud 体系还缺失一些关键的微服务基础组件，比如 Metrics 监控，健康检查和告警等。

这些情况导致了开发人员在实际工作中无法高效、快速地构建出适用于企业生产环境的微服务架构，而是要花不少时间和精力走很多弯路，同时也对部分工程师通过实践的方式来学习微服务架构相关知识带来了一定的障碍。

红帽公司中间件部门工程副总裁Mark Little博士也曾说过：“我在微服务架构方面担心的问题之一就是，你有一个整体式单体架构应用，假设你随意把它分解成多个服务，到头来就会分解得过细，最后会有10个、100个甚至1000个微服务。但是这些微服务又彼此高度依赖，以至于如果某一个服务出现故障，其余服务很有可能也会出现故障。这种情况下，你将一无所获。你有999个服务就在那里干等着另一个服务恢复正常运行之后才能工作。”