做为微服务架构的忠心拥趸，虽然有时也会对其感到不爽。使用微服务时，我时常能感觉到“小中见大”、“稳中有快”等理念，另外一方面也会警戒“厨子太多烧坏了汤”。数据库
回顾 2014 年，公司正在经过采用微服务架构实施数字化转型。那时数字化、转型和微服务这些词对我就是天籁之音。编程
做为一名解决方案架构师，我很是但愿能了解这种新模式。为了跟上技术前沿趋势，我阅读了大量微服务架构相关的文章，与个人网络技术负责人交流，并研究了一些适用的用例。后端
那时我发自心里地相信微服务架构，确信单体应用将会消亡。设计模式
此后，我服务过的每家公司都已采用或正在采用微服务架构。虽然其中一些公司的领导团队并没能说服组织为何要选择微服务，一个广泛的回答是：“其余公司都在这样作，在每次会议上你们都说微服务是一种改变游戏规则的方式，因此咱们也这样作吧。”api
经过为各个业务领域中的多家公司提供体系结构和设计支持，我发现将现有的单体应用从新架构为微服务架构须要付出大量的耐心、时间和经验。安全
在给出我在采用微服务中的五点切身体会以前，首先从新审视一下什么是微服务？微信
有说法提出，这种架构样式事实并无一个的标准定义，只是存在一些“围绕组织和业务能力、自动部署，端点智能、对语言和数据分散控制”的特征。网络
在我看来，若是一个组织必须具有上述全部特征才能去使用微服务，那么咱们就不只是在谈论技术变革，而是在推进组织内的重大文化变革。架构
下面给出我在实践微服务中的五点主要体会。编程语言
1
跳出项目，拥抱产品
传统的软件开发方式中，开发团队一块儿构建一个单体应用软件，进而由生产支持团队管理该软件。在这种方式中，生产支持团队做为软件的新全部者，一般并不彻底了解组件的构建过程，例如代码的逻辑，所使用的技术等。
他们的核心工做是确保知足业务需求的生产系统能正常地运行，团队之间一般也没有定义有效的沟通途径。生产系统中出现的问题将致使开发回滚到某个还原点，或是给出快速的短时间修补。有时，生产代码中的一个微小问题将触发整个过程所有从新开始。而问题一般必须由原始开发团队解决，这致使总体延迟。
若是以瀑布式开发方式（即前期设计、集中式的版本发布流程、构建和部署）处理微服务，则存在巨大的风险。最终获得的多是一个更复杂的系统，没法享受微服务所承诺的任何好处。
在微服务中，常常说起的是“产品”，而非“项目”。使用微服务方法，利益相关者（包括用户、程序、产品和技术人员）致力于产品这一共同目标。在投资、软件交付到维护的整个过程上，产品模式都不一样于项目模式。
产品直接影响所提供的业务功能。不一样于传统方法中构建单体应用须要多个团队参与，微服务模式支持单个团队彻底负责构建和管理某一小部分软件。团队在产品模式下是稳定的、跨职能的，并以结果为导向的，独立完成“设计 - 构建 - 运行”全过程。
每一个团队都是遵循统一报告层级的独立部门，根据路线图去分块构建独立的软件单元。某一层上的团队可将另外一层上的团队视为他们的（内部）客户，相互协做去解决业务问题，而不是以权责交付的方式工做。
因为工程团队以产品模式工做，他们了解软件在生产中的行为，所以能够当即解决全部问题，避免产生延误。
CapitalOne 秉持 YBYO（You Build You Own，本身构建）理念，团队全权负责设计、构建、测试和部署生产环境中的软件。工程团队直接参与产品，并与用户互动。用户不断提供反馈，帮助团队构建高质量的产品。
要点：控制范围使团队能够更好地构建和管理微服务。产品模式支持与终端用户创建更紧密的合做、管理和构建关系。
2
思考宏观服务“微”构建
我在加入 CapitalOne 以前曾任职另外一家公司的团队，为公司的电子商务网站创建产品目录服务。该公司采用了微服务方法，产品目录服务以请求为准则，向最终用户提供产品列表。
因为个人团队控制着数据和目录数据库，所以选择 Java 和 SpringBoot 构建服务。这些编程语言支持丰富的软件库，咱们对此很是满意。服务最终公开提供在面向最终用户的 API 网关上。
公司中一样还有其余几个团队，使用各自的技术来构建本身的服务。从产品的角度来看，每一个功能都受到构建在异构平台上的各个服务的支持。这样的模型解决了一个重要的问题，那就是在招募和培训团队中，没必要使用相同的技术堆栈构建单体应用。在微服务模型中，每一个团队均可以选择适合自身业务需求的工具，据此招聘新的团队成员。
微服务是一种经过服务构建其中业务应用组件的体系架构。每一个服务都是业务流程中的一个独立于其余服务的逻辑软件单元。这种不依赖于其余服务和技术选择的自由度，打开了探索新技术、构建本地软件组件以及基于服务定义范围进行设计的大门。
在 CapitalOne，软件产品与业务功能是保持一致的。各个业务线（lines of businesses，LOB）构建和管理本身的产品。跨职能的业务线主要是用于构建和管理企业产品的，例如知足全部 LOB 需求的数据湖和平台。
要点：松耦合和紧关联的原则，支持团队构建各类解决更大业务问题的产品。
3
关键在于实现：RESTful一劳永逸
微服务架构其实是一种微组件架构。“微”指组件的粒度细，而不是指所暴露接口的粒度。微服务是以 API 为接口的组件，但并不是全部的微服务组件都暴露 API。在从单体应用向微服务架构过渡中，咱们能够保持暴露的 API 数量不变。
在这一过渡过程当中，肯定初始计划将须要几天甚至几个月的时间，反过来增长了初始阶段的前期成本。大型应用分解为微服务，可能须要更多团队的协做。其中持续存在着过分工程的风险，致使建立了比需求更多的微服务，增长了体系结构的复杂性。
我在加入 CapitalOne 以前曾任职的一个公司，肯定了一些可迁移到微服务架构的单体业务应用。产品的愿景并无发生改变，由于总体的业务功能没有改变。
公司招聘了更多的团队，指望这些团队担当起服务的全部者。公司根据发布时间表部署服务，但基础架构团队并未受到计划的影响，仍然掌控着生产系统。计划在启动两年后的进展不大，花光了预算。
如上的许多实例代表，公司内部团队应对微服务的实现作更好的沟通。实现数字化转型的不只仅是应用的开发和新的技术，还须要在产品分析、预算估算、架构、部署程序的从新设计、基础架构扩展等过程上作大量的工做。过渡到微服务，须要时间、金钱，以及对业务问题见解上的重大转变。
要点：微服务并不是只是一种架构方式，而是一种会影响到组织中每一个团队的文化变迁。
4
收益是长期的
采用微服务须要创建多个产品、服务和团队。在采用这种复杂的体系结构以前，组织必须确立一个扎实的路线图。
企业须要采用强大的企业级产品，支持各个团队以微服务方式工做，凝聚在一块儿。其中包括支持 API 文档的工具，以及源代码管理、问题追踪器和实现自动部署的工具等协做工具。
服务由工程团队构建，以 API 方式暴露在 API 网关上。API 网关相似于一个 REST API 的市场，是组织平常业务运营的骨干。一旦组织步入微服务方法的正轨，持续的服务流就能得以建立、升级、替换等。工程师可能并不知道每一个服务的确切位置，由服务发现系统支持服务的自动检测，使得服务之间能够互相发现。
为了得到更好的性能和故障隔离，微服务组件须要一个专门的基础架构。每一个微服务应具备本身的发布时间表，无需依赖于其余服务而随时部署到生产环境。所以，选择有效工具持续并实时监视和分析微服务的是相当重要的。
API 是微服务世界的接口，所以 API 的日志记录、性能监视和安全性也是组织中 IT 服务过程的关键。
构建有弹性的微服务，可遵循多种设计模式，例如，“重试模式”（Retry Pattern）经过透明地重试失败操做尝试链接到服务或网络资源，支持应用处理瞬态故障；“断路器模式”（Circuit Breaker pattern）支持应用在链接远程服务或资源时发生错误时能很好地处理故障。
这样避免了微服务生态系统中出现级联故障，进而提升应用的稳定性和弹性。在微服务中，每一个服务都是独立的组件，每一个功能和服务均可以扩展，而没必要扩展整个应用。关键服务可部署多个实例，实现高可用性和更好的性能，而不会影响其余服务的性能。
要点：尽管过渡到微服务需在前期需投入大量的资源和工做，但随着时间和工做上的付出，以及自动化工具的使用，业务将从中受益，可快速向市场交付有质量产品。
5
微服务并不普适
并不是全部的业务和用例都适用微服务。例如，团队必须构建具备不多功能的简单应用，或是大型单体应用没法拆分红较小的模块，或是不了解微服务体架构所带来的权衡。
此外，某些企业可能还没有具有快速开发和部署应用的能力，或是不须要持续监视应用或业务，由于发生故障的恢复时间较长对业务影响不大。
和全部其余工具同样，微服务只是一种工具，并不是普适于全部业务问题的解决方案。业务优先于一切，底层系统则能够适应任何体系架构模式，不管是单体应用仍是微服务。
在决定使用微服务以前，每家企业必须首先了解自身的业务需求，权衡利弊后再决定是否转向微服务。
CapitalOne 在彻底采用云和微服务架构以前，投入了大量时间和精力研究微服务应用。有能力的领导、富有远见的产品团队和技术精湛的工程团队通力合做，使得 CapitalOne 实现了银行技术领导者这一目标。
要点：使用微服务并不是免费的午饭。
使用微服务架构将致使基础架构的需求、成本和复杂性激增，那么企业为何要采用微服务？具备大客户群的大公司，将经过在短期内向客户提供优质的产品而蓬勃发展。他们的系统须要始终保持运行的状态，为分布在各个地区的客户提供服务。
微服务是一种有助于实现此目标的解决方案。在当今的世界中，随着云原生基础架构的出现、DevOps 交付管道的自动化以及容器的采用，公司应该研究一下微服务的优点。
须要指出的是，企业决定选用某种技术，并不是彻底由于别人用着很酷。相反，在采用微服务以前，咱们须要花费时间和精力去了解这种架构模式，该架构与企业自身的相关性。但愿个人切身体会能有助于读者深刻了解微服务。
- END -
往期回顾
点一下在看再走吧
本文分享自微信公众号 - 互联网后端架构（fullstack888）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。