正文
微服务架构给我们带来方便的同时，也引入一定的系统复杂性，最近几年随着基础设施自动化技术的发展，比如云平台、容器技术，再加上自动化测试与持续集成，减少了构建、发布、运维微服务的复杂性。因此我们的微服务团队应该依赖基础设施自动化技术构建软件，下图说明这种构建的流程：
基本的构建流程
在构建微服务软件时使用的分布式服务框架也拥有很多特性，这些特性提供了很多复杂问题的解决方案，比如异步调用、超时失败策略、故障隔离、健康检查、流量控制以及自定义路由等，这些特性大大减轻了开发者处理逻辑的负担，还有一些高性能、高可用的保障都增加了我们构建微服务的信心。而且经过多年的微服务实践者的摸索，也总结出了很多辅助运维系统，比如统一日志收集（ELK）、服务管理、服务监控和服务治理等，大大减轻了运维的工作，而且能让我们对复杂的微服务系统做到心中有数。
总之，微服务架构入坑容易，坑了呆得舒服难。各种基础设施和配套系统必须跟得上，还得有一个具有微服务特性的团队，才能真正驾驭得了微服务。
两个值得深入的话题：
-
-
上一节中说到更适合构建微服务应用的微服务团队，什么时微服务团队？说一个比较现实的问题，当我们做服务拆分的时候，通常管理都会集中在技术层面，涉及到UI团队、服务端业务逻辑团队、数据库团队、测试团队和运维团队。当采用这种标准对团队进行划分时，即使时小小的变更都将导致跨团队项目协作，从而消耗时间和预算审批。这就是 Conway's Law ：
设计一个系统的任何组织（广义上）都会产生这样一种设计，其结构是组织交流结构的复制。
