微服务是当前软件开发领域的技术热点。不过，随着云原生技术的推广以及大量微服务的落地，反微服务的声音越来越响亮。特别是今年 Istio 1.5 版本发布，其控制面由原来的多个微服务组件合并成了一个单体应用，极大地简化了架构以及部署运维的复杂性，获得了一致好评，社区中对微服务模式质疑的声音也接连不断。
那么，微服务到底能给业务带来哪些好处呢？在云原生时代又该如何更合理地落地微服务呢？
架构没有好坏优劣之分，只有适合与不适合。但将微服务架构与单体架构进行比较，就会发现微服务具有以下优点：
首先，微服务独立运行，以进程方式隔离，能够有效控制故障范围，让架构更可靠。
其次，微服务架构因为故障被有效隔离，整体可用性更高，降低了单点故障对整体的影响。
再者，微服务粒度更小，架构演进的影响面也更小，不需要大规模重构，只需调整个别微服务就行。
然后，微服务架构可以实现以服务为粒度，通过接口共享重用，可重用性更高。接着，微服务架构能够根据服务对资源的要求以服务为粒度进行扩展，可扩展性更灵活。最后，服务拆分后，各个服务可以独立并行开发、测试、部署，交付效率大幅提升，产品更新换代速度加快，用户体验也更好。
1. 团队调整
团队需要重新组建，要以服务作为核心，按照业务领域来划分全功能团队，同时对原有的研发流程和决策机制进行改变。比如，要倡导敏捷文化、做到快速迭代，进行更多的自动化测试，并且加强代码审查（Code Review）等工作。此外，微服务框架能够对分布式场景下的一些常用能力（如负载均衡、容错、远程通信等能力）进行封装和抽象，这样开发人员就可以快速开发出高质量的服务了。所以，在采用微服务之前，应该先进行微服务架构的选型、学习和试用工作，使整个团队储备一定的微服务相关知识。
2. 基础设施建设
基础设施即代码，它能通过编程来管理虚拟机或容器，无需手动配置和更新各个硬件，这让基础设施富有弹性，能够快速、高效且准确地进行重复性操作。开发人员利用同一套代码或配置，就能部署并管理数量众多的物理机。
此外，当服务数量增多、交付频繁时，故障次数可能大幅增加，所以需要构建全面的监控体系来发现故障并及时处理。在生产环境出现问题时，还需对故障进行分级，评估影响范围，再分配给相应负责人。
微服务架构的一大优势是快速交付，这既体现在服务粒度更小，也体现在整个流程更加快速。因此需要打造基于自动化的工具链，以流水线交付的方式将整个 DevOps 流程串联起来。这样一来，小团队就可以基于服务进行独立的开发、测试、部署和运维。这两点并非采用微服务模式的充分必要条件，但如果能够满足，微服务化的过程会更加顺利，后续的维护和迭代也会很轻松，而不是困难重重。
另外需要注意，微服务应该随着业务的发展逐步拆分。几乎所有成功的微服务架构都是从庞大的单体架构拆分而来，而几乎所有一开始就构建微服务架构的案例，后续都遇到了很大的困难。面对新的业务和领域，我们在开始阶段很难把业务梳理得非常清晰，往往是经过一段时间、经历一些挫折后，业务内部的架构才逐渐清晰。从已有的模块清晰的单体架构逐步划分服务，比一开始就构建微服务要简单得多。否则会有两个弊端：一是第一版的交付时间会大大延迟，因为需要构建很多公共服务；二是服务很容易拆分不合理，严重影响整个调用流程的性能，甚至可能需要花费大量精力处理分布式事务，最后不得不把多个微服务重新整合成一个单体。
而且，只有当业务复杂度达到一定程度后，微服务架构消耗的成本才会体现出优势。微服务设计应该遵循垂直划分优先原则，这样可以让团队自上而下地关注业务实现，做到端到端负责，避免因跨服务多次调用而产生的性能和沟通成本。
