微服务是当前软件开发领域的技术热点。不过，随着云原生技术的推广以及大量微服务的落地，反微服务的声音越来越响亮。特别是今年 Istio 1.5 版本发布，其控制面由原来的多个微服务组件合并成了一个单体应用，极大地简化了架构以及部署运维的复杂性，获得了一致好评，社区中对微服务模式质疑的声音也接连不断。

　　那么，微服务到底能给业务带来哪些好处呢？在云原生时代又该如何更合理地落地微服务呢？

　　架构没有好坏优劣之分，只有适合与不适合。但将微服务架构与单体架构进行比较，就会发现微服务具有以下优点：

　　首先，微服务独立运行，以进程方式隔离，能够有效控制故障范围，让架构更可靠。

　　其次，微服务架构因为故障被有效隔离，整体可用性更高，降低了单点故障对整体的影响。

　　再者，微服务粒度更小，架构演进的影响面也更小，不需要大规模重构，只需调整个别微服务就行。

　　然后，微服务架构可以实现以服务为粒度，通过接口共享重用，可重用性更高。接着，微服务架构能够根据服务对资源的要求以服务为粒度进行扩展，可扩展性更灵活。最后，服务拆分后，各个服务可以独立并行开发、测试、部署，交付效率大幅提升，产品更新换代速度加快，用户体验也更好。

　　1. 团队调整

　　团队需要重新组建，要以服务作为核心，按照业务领域来划分全功能团队，同时对原有的研发流程和决策机制进行改变。比如，要倡导敏捷文化、做到快速迭代，进行更多的自动化测试，并且加强代码审查（Code Review）等工作。此外，微服务框架能够对分布式场景下的一些常用能力（如负载均衡、容错、远程通信等能力）进行封装和抽象，这样开发人员就可以快速开发出高质量的服务了。所以，在采用微服务之前，应该先进行微服务架构的选型、学习和试用工作，使整个团队储备一定的微服务相关知识。

　　2. 基础设施建设

　　基础设施即代码，它能通过编程来管理虚拟机或容器，无需手动配置和更新各个硬件，这让基础设施富有弹性，能够快速、高效且准确地进行重复性操作。开发人员利用同一套代码或配置，就能部署并管理数量众多的物理机。

　　此外，当服务数量增多、交付频繁时，故障次数可能大幅增加，所以需要构建全面的监控体系来发现故障并及时处理。在生产环境出现问题时，还需对故障进行分级，评估影响范围，再分配给相应负责人。

　　微服务架构的一大优势是快速交付，这既体现在服务粒度更小，也体现在整个流程更加快速。因此需要打造基于自动化的工具链，以流水线交付的方式将整个 DevOps 流程串联起来。这样一来，小团队就可以基于服务进行独立的开发、测试、部署和运维。这两点并非采用微服务模式的充分必要条件，但如果能够满足，微服务化的过程会更加顺利，后续的维护和迭代也会很轻松，而不是困难重重。

　　另外需要注意，微服务应该随着业务的发展逐步拆分。几乎所有成功的微服务架构都是从庞大的单体架构拆分而来，而几乎所有一开始就构建微服务架构的案例，后续都遇到了很大的困难。面对新的业务和领域，我们在开始阶段很难把业务梳理得非常清晰，往往是经过一段时间、经历一些挫折后，业务内部的架构才逐渐清晰。从已有的模块清晰的单体架构逐步划分服务，比一开始就构建微服务要简单得多。否则会有两个弊端：一是第一版的交付时间会大大延迟，因为需要构建很多公共服务；二是服务很容易拆分不合理，严重影响整个调用流程的性能，甚至可能需要花费大量精力处理分布式事务，最后不得不把多个微服务重新整合成一个单体。

　　而且，只有当业务复杂度达到一定程度后，微服务架构消耗的成本才会体现出优势。微服务设计应该遵循垂直划分优先原则，这样可以让团队自上而下地关注业务实现，做到端到端负责，避免因跨服务多次调用而产生的性能和沟通成本。

　　1. 选择合适的时机

　　在实际落地过程中，若想享受到微服务带来的好处，就需要做好一些前期准备工作。例如，组织架构和团队文化要与云原生的节奏相适应，要足够敏捷且足够自主；要构建全功能团队，将产品、UI、前后端研发、测试等角色配备齐全；要提前打造自动化的流水线，实现一键构建、发布、部署以及快速扩缩容等功能；服务也要提前进行容器化部署改造，因为服务容器化更有利于在云原生场景下集成其他功能组件。当上述准备工作全部完成，并且业务也逐渐发展到一定规模、急需进行拆分的时候，就应该当机立断地进行微服务拆分和架构设计了。

　　2. 选择合适的微服务框架

　　现在主流的微服务框架主要分为两类：侵入式与非侵入式。

　　主流的侵入式框架包括 Spring Cloud、Dubbo、brpc 等，这些框架的功能特色各有不同，在不同场景中均有应用，大部分架构师对它们都比较熟悉，其社区和文档的成熟度也都较高。虽然像 Spring Cloud 这样的传统侵入式微服务框架存在版本碎片化严重、升级成本高等问题，但总体而言，它们已经能够满足绝大部分服务治理的需求。

　　现在大部分人更关注非侵入式框架的选型，也就是近几年兴起的服务网格技术。2017 年，随着 Linkerd 的传入，Service Mesh 被翻译成服务网格，并开始进入国内社区的视野。部分大公司也同步自研了适合公司内部应用场景和依赖的服务网格框架，以此助力内部服务的快速迭代与发展。

　　而 Istio 作为一个开源的 Service Mesh 框架，一经推出就备受关注，成为各大厂商和开发者追捧的对象。很多人认为，Istio 会成为继 Kubernetes 之后又一个明星级产品。有了 Istio，基本上不再需要其他微服务框架，也无需自己去实现服务治理等功能。只要把网络层委托给 Istio，它就能完成这一系列工作。简单来说，Istio 是一个提供服务治理能力的服务网格。

　　此外，Istio 还具备完善的可观察性方面的能力，包括对所有网格控制下的流量进行自动化度量、日志记录和追踪。换句话说，选择了 Istio，单体应用无需进行任何改造就能轻松接入微服务，享受云原生的各项好处。

　　3. 借助云厂商产品快速进行云原生与微服务落地

　　之所以提及云厂商，是因为大多数中小型公司或者传统行业都被单体应用和传统微服务框架的种种弊端所困扰，迫切需要进行云原生和微服务的改造。然而，它们缺乏足够的人力和技术来维护一套具备齐全功能的云原生底座和基础架构服务。以 Istio 框架为例，它的版本更新频繁，控制面和数据面在提供强大功能的同时，其代码实现也相当复杂。当出现异常时，很多工程师往往难以定位问题所在。而云厂商提供了一整套云原生应用编排和微服务管理的解决方案，所有技术都实现了产品化，方便使用且易于查看效果，还能避免或者快速解决运行期间可能遇到的各类问题。从一定程度上来说，这既提高了服务效率，又大幅降低了各种成本，能够让人快速且充分地享受到云原生的好处。

　　总的来说，任何软件或者架构都有其优缺点，不存在十全十美的事物。当大家在考虑是否要落地微服务时，需要思考和权衡的是：当前的软件和系统是否满足微服务化改造的前提条件，微服务化改造后所带来的收益是否大于损失、好处是否多于弊端，团队在各个方面是否做好了准备。如果还没有准备好，那么不妨再等等，毕竟单体架构也有其自身的优势。