微服务架构可谓是当前软件开发领域的技术热点，它在各类博客、知识媒体和业界知名会议演讲上的出镜率很是之高，不管是作基础架构仍是作业务系统的工程师，对微服务都至关关注，而这个现象与热度已经持续了近5年之久，经久不衰。数据库
然而，随着云原生技术的推广，以及大量的微服务落地，反微服务的声音愈加响亮。尤为是在今年3月初，服务网格的著名开源项目 Istio 发布了 1.5 版本，其控制面由原先的多个微服务组件，合并成了一个单体应用，大大简化了其架构与部署运维的复杂性，赢得了满堂喝彩。社区关于微服务模式质疑的声音此起彼伏，也有文章大声呼喊：“醒醒，你不是真的须要微服务！”编程
那么，在云原生时代，是否须要微服务？何时应该采用微服务？微服务究竟能给业务带来哪些好处？如何在不一样环境下正确合理地落地微服务？但愿读完本文后，每位读者都能在心中有个答案。后端
微服务是什么
2014年，Martin Fowler 与 James Lewis 共同提出微服务的概念，定义了微服务架构是以一组小型服务的方式来开发一个独立的应用系统，每一个服务都以一个独立进程的方式运行，每一个服务与其余服务使用轻量级（一般是 HTTP ）通讯机制。这些服务是围绕业务功能构建的，能够经过全自动部署机制独立部署，同时服务会使用最小规模的集中管理能力，也能够采用不一样的编程语言和数据库，实现去中心化的服务管理。服务器
而早在 2005年，Peter Rodgers 博士在云端运算博览会上就提出了微 Web 服务，将程序设计成细粒度的服务（Granular Service），以做为 Microsoft 下一阶段的软件架构。网络
由此能够看出，微服务并非一个新的概念，在很早以前就有了充足的理论基础。大系统终究会拆解成小系统，“合久必分，分而治之”；传统行业的系统架构大多都是庞大的单体架构，微服务是架构发展的一个很是天然的演变状态。架构
遗憾的是，微服务模式并不是“银弹”，微服务也有其弊端和痛点。Martin Fowler 也在他的博客中写道：“除非你的系统太复杂，做为单体应用会很难管理，不然不要考虑微服务。绝大多数软件系统都应该构建为单体应用。要注重在单体应用中实现良好的模块化，但不要试图将其拆分红单独的服务。”并发
微服务架构的优势
一般来讲，架构没有好坏优劣之分，只有适合与不适合。可是当把微服务架构与单体架构进行比较，会发现微服务有以下一些优势：负载均衡
| 因素 | 单体架构 | 微服务架构 | 说明 |
|---|---|---|---|
| 故障隔离 | 线程级 | 进程级 | 微服务独立运行，经过进程的方式隔离，使故障范围获得有效控制、架构变得更可靠。 |
| 总体可用性 | 较低 | 较高 | 微服务架构因为故障获得有效隔离，总体可用性更高，有效下降了单点故障对总体的影响。 |
| 架构持续演进 | 困难 | 容易 | 微服务的粒度更小，架构演进的影响面相应也更小，架构演进不须要大规模重构，只需调整个别微服务便可。 |
| 可重用性 | 低 | 高 | 微服务架构能够实现以服务为粒度，经过接口共享重用。 |
| 可扩展性 | 笨重 | 灵活 | 微服务架构能够根据服务对资源的要求以服务为粒度进行扩展，而单体应用只能总体进行扩展。 |
| 交付速度 | 较慢 | 较快 | 服务拆分后，各个服务能够独立并行开发、测试、部署，交付效率大大提高，产品更新换代速度更快，用户体验更好。 |
微服务还有许多优势，如“反脆弱性（anti-fragility）”、架构抽象、技术隔离等。但并非说采用了微服务就天然地具有了这些特性。框架
微服务的先决条件
准确地来说，要想享受微服务的福利，须要具有一些先决条件。
1、团队调整
须要从新组建团队，以服务为核心，按照业务领域划分全功能团队，改变原有的研发流程、决策机制。例如，倡导敏捷文化、快速迭代，作更多的自动化测试，增强 Code Review 等。运维
在新的团队组织里面，一切以人为本，须要创建开放自由的环境。领导对下级高度信任，加强其自我驱动，充分发挥每个人的力量，而不是让工程师成为“螺丝钉”。
微服务框架能够封装、抽象分布式场景下的一些经常使用能力，例如负载均衡、服务注册发现、容错、远程通讯等能力，可让开发人员快速地开发出高质量的服务。所以，在采用微服务架构以前，应该先进行微服务架构的选型、学习和试用。整个团队要对微服务的基本概念、微服务框架的实现原理，微服务治理与监控等知识须要有必定的储备。
2、基础设施建设
基础设施即代码，能够经过编程的方式管理虚机或容器，免去了手动配置、更新各个硬件的环节，这就使得基础设施极具弹性，可以快速、高效、准确地进行重复性操做。开发人员使用同一套代码或配置，就能够部署并管理成千上万台物理机。
当服务数量增多、交付频繁的时候，故障次数可能会大幅度上升，咱们须要经过全面地监控发现故障，及时处理并发出警报。当生产环境出现问题的时候，须要将故障进行分级，评估影响面，并分配给相应的负责人。
微服务架构的一个大优点就是快速交付，快速交付不止体如今服务的粒度更小，能够独立交付，还体如今整个流程更快速。微服务架构基于自动化的工具链，以流水线交付的方式串联整个 DevOps 流程。小团队能够基于服务独立开发、测试、部署、运维。
以上这两点不是采用微服务模式的充分必要条件，但当团队知足了上述两个条件后，微服务化的过程将事半功倍，后续维护和迭代也会顺风顺水，而不是叫苦不迭。
微服务是逐步拆分出来的
其次，微服务是应该随着业务的演进逐步拆分出来的。
避免在设计系统的时候直接划分微服务。几乎全部成功的微服务架构都是从一个巨大的单体架构拆分出来的；几乎全部在一开始就构建微服务架构的案例，后续都遇到了巨大的困难。
面对一个新的业务和领域，很难在开始阶段就对业务梳理得很清晰，每每是通过一段时间踩过一些坑，通过模块调整后，业务内部架构才能逐渐清晰起来。而且从一个已有的模块清晰的单体架构逐步划分服务，要比一开始就构建微服务简单的多。若是一开始就划分了微服务，其一，初版交付的时间会延后许多，由于有许多公共服务须要去构建起来；其二，服务很容易拆分得不合理，大大影响整个调用流程的性能，甚至可能须要花费很大的精力去处理分布式事务，最后不得再也不将多个微服务整合成一个单体。
只有当业务复杂度达到必定的程度后，微服务架构消耗的成本才会体现其优点，这个时候就能够开始设计微服务架构、进行微服务划分了。微服务设计应该优先尊崇垂直划分优先原则，垂直划分服务可让团队自上而下地关注业务实现，端到端负责，避免跨服务屡次调用引发的性能与沟通成本。
微服务须要监控与治理
拆分以前，整个系统拥有的服务数通常只有个位数；拆分以后，服务可能变成了数十上百个，实例数可能会达到成千上万个。这么多服务与实例，须要构建一套监控系统，可以监控全部服务平常运行状态，而且须要在服务出错的时候给对应负责人发出报警信息；在出现故障时，可以经过调用链查询以及服务拓扑图等功能进行分析查看，也能够进一步查看到全息日志等具体信息。
除了监控，服务治理也相当重要。能够经过 SDK/Sidecar 手段提供服务高可用的治理策略，这些策略每每对业务是非侵入或者弱侵入的，可以让绝大多数服务轻松实现服务高可用。
微服务之间一旦创建起路由，就意味着会有数据在服务之间流通。因为不一样服务能够提供的资源和对数据流量的承载能力不尽相同，为了防止单个 Consumer 占用 Provider 过多的资源，或者突发的大流量冲击致使 Provider 故障，须要服务限流来保证服务的高可用。
在服务治理中，虽然咱们能够经过限流规则尽可能避免服务承受太高的流量，可是在实际生产中服务故障依然难以彻底避免。当整个系统中某些服务产生故障时，若是不及时采起措施，这种故障就有可能由于服务之间的互相访问而被传播开来，最终致使故障规模的扩大，甚至致使整个系统奔溃，这种现象咱们称之为“雪崩”。熔断降级其实不仅是服务治理中，在金融行业也有很普遍的应用。好比当股指的波动幅度超过规定的熔断点时，交易所为了控制风险采起的暂停交易措施。
负载均衡是高可用架构的一个关键组件，主要用来提升性能和可用性，经过负载均衡将流量分发到多个服务器，同时多服务器可以消除这部分的单点故障。
如何在云原生时代落地微服务
1、选择合适的时机
就像前面提到的，组织架构与团队文化要适应云原生的节奏，须要足够敏捷、足够自主，构建全功能团队，产品、UI、先后端研发、测试等角色要齐全；须要提早作好自动化的流水线，能够一键构建、发布、部署，能够快速扩缩容等；服务提早作好容器化部署改造，服务容器化更适合在云原生场景下集成其余功能与组建。等上述一切都 ready 了以后，而且业务也逐步发展到了必定规模急需拆分了，这个时候就应该果断进行微服务拆分和架构设计了。
2、选择合适的微服务框架
如今主流的微服务框架主要分为两类：侵入式与非侵入式。主流的开源侵入式框架包括 Spring Cloud、Dubbo、brpc 等，其功能特点各有千秋，在不一样的场景均有应用，大部分架构师对其均有比较多的了解，社区和文档的成熟度都比较高。虽然 Spring Cloud 这样的传统侵入式微服务框架大多具备版本碎片化严重、升级成本高等问题，但总的来讲，已经能够知足绝大部分服务治理的需求，而且借此快速推动微服务化改造。
如今大部分人更关心的是非侵入式框架的选型，即近几年火起来的服务网格技术。2017年，随着 Linkerd 的传入，Service Mesh 翻译成服务网格，并开始进入国内社区的视野，部分大公司也同步自研了适配公司内部应用场景和依赖的服务网格框架，用以助力内部服务快速迭代与发展。
而 Istio 做为一个开源的 Service Mesh 开源框架，一经推出就备受瞩目，成为了各大厂商和开发者争相追捧的对象。不少人相信，Istio 会成为继 Kubernetes 以后又一个明星级产品。有了 Istio，你几乎能够再也不须要其余的微服务框架，也不须要本身去实现服务治理等功能。只要把网络层委托给 Istio，它就能帮你完成这一系列的功能。简单来讲，Istio 就是一个提供了服务治理能力的服务网格。此外，Istio 还提供完善的可观察性方面的能力，包括对全部网格控制下的流量进行自动化度量、日志记录和追踪。换句话说，选择了 Istio，单体应用无需作任何改造便可轻松接入微服务，享受云原生各项福利。
3、借助云厂商产品快速进行云原生与微服务落地
之因此提到云厂商，是由于大部分中小型公司或者传统行业都面临着单体应用和传统微服务框架的各类弊端和诟病，急需进行云原生与微服务改造，可是缺少足够的人力与技术，去维护一套功能齐全的云原生底座与基础架构服务。例如 Istio 框架，其版本迭代频繁，控制面与数据面在提供了强大的功能的同时，代码实现至关复杂，在遇到了异常的时候，不少工程师每每很难定位问题。
而云厂商则提供了一整套云原生应用编排与微服务管理解决方案，全部技术都获得产品化，方便使用与查看效果，而且避免或者快速解决运行期间可能遇到的各类问题。在必定程度上，这不只提升的服务的效率，也大大下降了各类成本，能够快速充分地享受云原生福利，助力内部业务稳定对外服务，快速扩张。
总结
最后，咱们再回到开篇的疑问，咱们是否还须要微服务？
这个问题没有惟一与正确的答案，每一个人所处的场景不一样，正如一千我的心中有一千个哈姆雷特。任何软件或者架构都有其利弊，没有十全十美的东西。你们须要思考和衡量的是，当前的软件与系统是否知足了微服务化改造的前提，微服务化改造后其带来的收益是否大于损失、利是否大于弊，团队各个方面是否作好了准备，若是尚未，那么请你再等等，单体架构也挺好！
做者简介：罗广明，现就任于百度基础架构部云原生团队，云原生技术专家，云原生社区联合创始人，ServiceMesher 社区管委会成员，多年来一直从事微服务技术与产品的研发工做，对 Spring Cloud、Istio 以及微服务中间件有深刻研究和实战经验。
参考文献
-
《持续演进的 Cloud Native 》 王启军/著
-
《Istio Handbook——Istio 服务网格进阶实战》ServiceMesher社区联合编著：https://www.servicemesher.com/istio-handbook/
-
《混合微服务高可用在企业级生产中的实践》 罗广明：https://cloudnative.to/blog/microservices-ha-practice/