标签：注册 http tor 建议 成熟 你知道 如何 人生 进程
昨日好评博文：《如何设计出优美的Web API？》
截止目前阅读量近 2000，获得好评无数，小伙伴们不要错过哦！
微服务是当下最流行的应用架构技术了，它跟容器服务、DevOps合称云时代的三剑客，可以帮我们化解业务发展过快导致的产品迭代压力，让我们可以自由选择最适合团队的技术栈，让系统能够承载互联网海量用户的访问，让我们可以更加轻松地运维大型的互联网系统。近些年在厂商、社区和用户等各方努力推动下，微服务相关的理论和产品都日趋成熟，不同语言的微服务开发及治理套件（例如：Spring Cloud/Dubbo等）让我们从零开始搭建微服务变得非常简单快捷，那我们是否就此可以全面进入微服务时代呢？
微服务的演进成熟需要时间，我们熟悉掌握这套新技术也需要时间，除此之外机房里面还跑着大量的单体式应用，它们需要继续维护和升级，任何时候我们都不可能抛开历史轻松上阵。这些单体式应用还担负着公司的核心业务，全部推倒重来、休克式重构是不可取的，投入大周期长，风险完全不可控。我们必须学会边行车边换胎的技能，在不影响现网业务的前提下推动微服务改造，让老系统焕发新的生命力，继续支持业务下一个十年的发展。本文将跟你一起探讨微服务改造相关的经验方法，让你更加从容地拥抱微服务！
如何从单体式应用演进至微服务呢？这些单体式应用都存在很长时间了，经过这么长时间的修修补补，体量规模都比较大，尤其是经过几波人交接维护，业务逻辑也变得异常复杂。同时，它们都在线对外提供服务，全部推倒重建的可能性微乎其微，休克式重构投入大周期长，风险也不好控制，还会影响业务对外服务的连续性。从现实情况出发，最可行的架构优化方案就是渐进式的微服务改造，按照业界的最佳实践和个人经验，该演进策略主要包括三个关键步骤：
通常单体式应用所采用的技术相对较老旧，维护这些系统的同事缺少机会学习实践当前主流的技术，久而久之就跟不上主流技术的发展，在晋升、加薪和跳槽时都缺乏竞争力，这会影响到个人的价值。随着系统规模越来越庞大，更新升级和运营维护的难度越来越大，每次发版都要加班加点和心惊胆战，逐渐满足不了业务快速发展的需要。在单体式架构之下，团队无法利用不同技术栈的优势解决不同场景下的问题，即使解决了问题也是事倍功半。
当意识到有必要将单体式应用改造成微服务时，我们通常会认为改造就是将单体式应用一块一块地敲下来改成微服务，这种想法是最直接的，但难度和风险也是最大的。改造初始我们对微服务相关技术也比较生疏，再加上拆解单体式应用本身的难度，双重困难叠加往往会导致改造失败或延期。
最靠谱的策略是先停止往单体式应用里面添加新的特性，所有新特性都构建成微服务，从而遏制单体式应用继续生长。新特性通常不会太复杂，新建微服务也要比从单体式应用上剥离微服务容易一些，借助这个过程让团队逐渐熟悉掌握微服务技术栈，从小规模练兵再到全面铺开。常见的微服务架构如下图所示，主要包含以下几大必备组件：
新特性全部构建成了微服务，但老特性还依旧在单体式应用当中，许多业务还需要新旧系统彼此协作才能完成，那么微服务和单体式应用之间还存在彼此交互。但新旧系统对外服务时所采用的协议可能不同，例如：采用Spring Cloud框架开发的微服务主要以RESTful HTTP API对外服务，采用Dubbo框架开发的微服务以Dubbo协议对外服务，而单体式应用可能以Web Service、EJB T3、不规范HTTP API等形式对外服务。除了协议不同之外，新旧系统对领域模型的定义也可能不同，包括名称和属性等，如何调和微服务和单体式应用的不同呢？
在微服务和单体式应用之间构建一道反腐层，这或许是最切实可行的办法。通过反腐层完成新旧系统的对接集成，又可以避免旧系统领域模型对新系统的干扰，让彼此保持松耦合状态，阻止旧系统的腐烂蔓延至新系统。反腐层还可以对单体式应用进行服务化封装，让其像微服务一样以RESTful HTTP API的方式对外服务。反腐层支持双向通讯，重点解决新旧系统对接集成、协议适配和模型转换等问题，按照此功能定位我们可以将反腐层划分成三个模块：
由于单体式应用的架构较为简单，因此在设计之初它们很少考虑系统集成相关的设计，通常一个应用下的不同服务拥有各自的入口，外观（Facade）就是解决此问题的，统一单体式应用对外服务的格式，像微服务一样以RESTful HTTP API的方式对外服务，规范接口的协议类型、URL命名和报文格式等。如果旧系统不属于我们维护，那反腐层就需要包含Facade模块，微服务通过它对接旧系统。如果旧系统也是由我们自己维护，那建议将Facade模块构建在单体式应用内部，微服务通过Adapter模块对接旧系统。
在旧系统周边构建微服务，遏制旧系统的不断生长，然后再从旧系统逐步剥离出微服务，最后完成对单体式应用的绞杀。优良的微服务设计同样遵循高内聚、低耦合原则，将关联紧密的行为封装进一个微服务当中，从而可以减少需求变更所影响的范围。只要服务契约不发生改变，那对单个微服务的升级改造都不会影响到其他服务，因此可以发布更少的服务来快速地满足业务需求，并降低同时部署多个微服务时带来的风险。在从单体式应用剥离微服务之前，我们先看看功能模块之间的边界有哪些类型：
领域驱动设计（DDD）理论提出了有界上下文（Bounded Context）概念，这是我们厘清服务边界的有效工具，我们可以借助它从单体式应用上剥离微服务。因此，单体式应用的微服务化改造，亦或新建微服务，我们都离不开业务专家的支持，通过他们确定有界上下文的划分，从而设计出好的微服务。
在前面章节中我们已经知道在微服务改造过程中需要构建反腐层，那在实际项目当中反腐层会以什么样的形态存在呢？通常我们会将反腐层设计成隔离网关，以单独的进程运行，在隔离网关内部实现Facade、Adapter和Translator等功能模块。隔离网关不需要从零开始建设，我们可以在Nginx、Kong、Zuul等开源中间件基础上扩展，它们都支持插件化或过滤器等扩展定制模式，我们很容易实现反腐层需要的功能。
通过反腐层（隔离网关）微服务可以与单体式应用进行正常通信，同时彼此之间保持松耦合，单体式应用可以不用做伤筋动骨地改动，微服务可以采用最新的技术独立演进，但这种方案下这些遗留的单体式应用是无法享受到云原生带来的好处。有没有一种方案可以让这些遗留系统也享受到服务发现、流量控制、服务熔断、服务降级等新特性呢？
Service Mesh，下一代微服务架构，可以给我们带来更加完善的解决方案，它将原先通过微服务开发框架（例如：Spring Boot等）侵入到应用内部的服务治理等功能模块封装进了Sidecar，与应用结对部署，作为独立的进程存在，这样可以做到与应用松耦合，架构上更加灵活，可以支持微服务治理相关基础设施的独立升级部署，还可以支持多语言。如果在Sidecar基础上再扩展隔离网关的功能，那遗留的单体式应用也可以更加融入微服务架构了。
本章节我们将梳理从单体式应用剥离微服务的一些常见场景和方案。在谈具体案例之前，我们有必要先了解一下业界最佳实践的经验总结，它主要包含以下几个基本步骤：
从业务开始，再到代码，最后才是数据，这就是上述三个步骤的关键。业务是所有代码和数据的源头，面向对象设计（OOD）和领域驱动设计（DDD）是做好微服务设计的专业技能，而用好这两项技能的前提就是对业务有深刻的洞悉，在（下）篇中我们将一起来看看具体的拆解场景，敬请期待！今天先分享到这里，如果你觉得有价值，麻烦动动手指点下文 「 推荐 」按钮，让更多小伙伴可以看到，我也会更加有动力坚持分享。另外，老兵哥我后续还会分享职业规划、应聘面试、技能提升、影响力打造等经验，欢迎 关注 本专栏或歪信公主号 「 IT老兵哥 」！
关注「 IT老兵哥 」，赋能程序人生！
标签：注册 http tor 建议 成熟 你知道 如何 人生 进程
原文地址：https://www.cnblogs.com/itlaobingge/p/12095774.html
