一篇文章即可了解「你的公司到底需不需要微服务」

2018 年 6 月 21 日 InfoQ

最近一段时间，好像人人都对微服务推崇不已，仿佛它可以拯救你那庞大而老旧的数据库，解决你目前项目中存在的所有问题，但是任何技术都不是银弹，它解决不了所有的问题。本文将尝试带领你剖析，什么条件下，你的团队需要微服务架构。

也许你正在经历下面的开发流程

试想一下，你目前正在开发一款软件来对抗你的竞争对手，当你把产品的核心需求梳理完毕后，整个项目进入开发阶段，你会手动创建一个新项目，也许你会用到 Maven来构建你的项目并管理项目所需的 jar包，然后整个项目将以商业逻辑为核心，它由定义服务、域对象和事件各模块来完成，各种适配器围绕核心与外部交互。适配器包括数据库访问组件、生成和 consume 信息的消息组件，以及提供 API 或者 UI 访问支持的 Web 模块。应用仍然以整体来打包和部署，然后部署在 Tomcat 或者 Jetty 这样的应用服务器。

也许这是你每天必备的工作，但同时，你也因此踏入了单体架构的地狱。几年之后，当这个项目迭代了多个版本后，你会发现应用变得庞大而复杂，你的开发团队也将饱受折磨，苦苦挣扎于敏捷开发和交付，甚至修复 bug 要远远比开发新功能所付出的时间还要多，这样的前提还是你没有产出新的 bug。试想一下，如果你目前正在维护一个十万行的 JSP文件，你的心里是什么感受。

微服务带来的好处

有很多公司，比如 NetFlix和 Amazon等，都通过微服务的方式极大的缓解了以上的问题，其本质就是将一个巨大的单体应用拆分成很多个互相连接的微服务，这样如果一个服务挂掉后不会对整个应用产生致命的影响。简单来说，实施微服务，整个公司的架构会有如下的好处：

每项微服务相对较小，易于开发者理解其业务逻辑，Web容器启动速度更快，提高开发者生产效率并可加快部署速度；
每项服务皆可独立的开发和部署，并且部署简单，大大简化频繁部署新服务版本的流程；
改善故障隔离，就如之前所说，一个微服务挂掉后，整体应用的其他功能不受影响，利于后期维护；
微服务架构模式使得每个服务独立扩展，可以根据每个服务的规模来部署满足需求的实例；

既然微服务有这么多好处，那是不是所有公司都可以直接用微服务来解决业务上的问题呢？之前说过，没有任何一项技术是完全的阳春白雪。

实施微服务的先决条件

针对微服务实施的先决条件，之前 Phil Calçado有过一段很精彩的论述，他说，“当你决定采用微服务，你将经历从单一应用到一个复杂系统的转变过程。在这个系统里，你会遇到很多无法预测的行为，因为团队和服务在持续地发生变化，它们被创建、被修改，然后被销毁。系统的快速变更能力为你的组织带来了巨大的好处，不过你需要确保你有一些安全护栏，否则你的交付会因为无穷无尽的变更而驻足不前。”

Phil Calçado总结了，如果你的团队要实施微服务，要满足以下的先决条件。

快速配置：具备在短时间内配置好一台服务器的能力；
基本的监控：生产环境中，很多轻度耦合的服务在一起协作容易出现问题，而这些问题在测试环境中难以被发现，所以我们需要一个有效的监控机制来快速地检测这些问题；
快速部署：因为需要管理的服务太多，所以需要尽快地部署它们，不管是在测试环境还是在生产环境；

同时，他在实践中也总结出，易分配的储存、标准的 RPC等因素也是决定一个微服务成败的先决条件，所以，Phil Calçado列出了关于微服务先决条件的完整清单如下（按照优先级从上到下）：

计算资源的快速分配
基本的监控
快速部署
易于分配的存储
易于访问的外围
认证和授权
标准化的 RPC

所以，一个团队如果想成功实施微服务还是有不少的问题有待解决，如果有一位业内顶级的专家给你指导，手把手教你在微服务实施中如何避免各种坑，那你一定会节省很多时间。

如果你对微服务感兴趣，不妨关注一下 7月 8日 -9日，在深圳·华侨城洲际酒店举办的 ArchSummit全球架构师峰会深度培训上，我们很荣幸地邀请到了 天弘基金（余额宝）移动平台技术总监 & 首席架构师——李鑫老师，他在 大规模分布式应用及治理、中间件云化及服务化（PaaS）、APM监控、基础开发平台等领域都有着非常丰富的经验，如果你想了解 微服务的治理模型，并想知道如何通过 “监控”及“管控”这两大能力的构建来综合解决 微服务的现实治理需求，那么本次培训将会是你最好的选择。