软件设计与体系结构 10-微服务架构

11-微服务架构1概述大多数体系结构风格都是由架构师命名的，他们注意到一种不断出现的特定模式。相反，随着软件开发生态系统的变化，许多架构师最终会做出共同的决定。处理这些变化并从中获利的常见最佳方式变成了其他人效仿的架构风格。微服务在这方面有所不同，它在使用上很早就被命名，并由MartinFowler和JamesLewis于2014年3月发表的一篇题为“Microservices”的著名博客文章推广开来。他们认识到了这种相对较新的架构风格的许多共同特征，并对其进行了描绘。2概述微服务体系结构由轻量级、松散耦合的服务集合组成。每个服务都实现了单个业务功能。理想情况下，这些服务应该是具有足够的内聚性，可以独立地开发、测试、发布、部署、扩展、集成和维护。微服务在很大程度上受到了领域驱动设计（DDD）思想的启发，DDD是软件项目的逻辑设计过程。特别是DDD中的一个概念，即限界上下文，无疑启发了微服务。限界上下文的概念代表了一种解耦风格。当开发人员定义一个域时，该域包括许多实体和行为，这些实体和行为在代码和数据库模式等构件中标识。例如，应用程序可能有一个名为CatalogCheckout的域，其中包括目录项、客户和支付等概念。3概述在传统的单体结构中，开发人员将共享其中的许多概念，构建可重用的类和关联的数据库。在限界上下文中，软件内部（如代码和数据模式）耦合在一起的方式进行工作；但它们从不与限界上下文之外的任何东西耦合，例如来自另一个限界上下文的数据库或类定义。这允许每个上下文只定义它需要什么，而不是容纳其他组成元素。微服务的主要目标是高度解耦，对限界上下文的逻辑概念进行物理建模。4Agenda什么是微服务如何拆解服务微服务的关键技术微服务的设计模式微服务项目实战5/72什么是微服务微服务架构几乎都是从ALLINONE的单体架构演进而来，中间又经历了分布式架构、面向服务架构的演进过程。6/72什么是微服务传统单体架构的核心分为业务逻辑、适配器以及API或通过UI访问的WEB界面。业务逻辑定义业务流程、业务规则以及领域实体。适配器包括数据库访问组件、消息组件以及访问接口等。尽管也是遵循模块化开发，但最终它们会打包并部署为单体式应用。例如Java应用程序会被打包成WAR，部署在Tomcat或者Jetty上。单体架构往往以烟筒式方式发展，往往存在两个主要问题：中心化和耦合度高。所谓中心化，就是数据集中存储在单个数据库中，业务系统集中部署在单台服务器上，通过集群部署方式提供服务能力。7/72什么是微服务然而中心化的问题，也就是单点问题。而耦合度高，主要是指其中一个功能模块升级，其它的模块都得一起升级。这里要说明下，模块依赖度高不是单体架构的错，是因为本来架构可能就没有设计好。但是，在实际场景中，随着快速迭代开发，研发换了一波又一波，产品走了一茬又一茬，难免系统架构腐化严重。看到了单体架构的诸多问题，系统开始通过按功能或模块进行拆分，拆分成多个独立的子系统，系统间通过RPC、MQ方式调用，由此逐渐演变为分布式的服务架构。分布式服务架构主要通过服务化和层次化进行解耦拆分。8/72什么是微服务《架构整洁之道》书中提到一点，系统可以降解为策略和层次，而架构设计就是把相同的策略分到同一个组件中，反之，分属于不同的组件。所以，架构设计可以通过分层设计，由高层次服务调用低层次服务，低层次服务通过接口向上提供服务，以实现系统之间的解耦。也正是在这一阶段，单体架构一下子被拆分成几个或几十个系统。9/72什么是微服务但是随着架构的发展，问题又接踵而来，在没有做好边界的划分之前，系统拆分的服务往往是松散的。正如《架构整洁之道》所讲：软件架构设计本身就是一门划分边界的艺术。所以，很多系统在这一阶段，又往往进行了服务内聚和去层次化的演变过程。❶所谓服务内聚，就是以领域驱动设计为原则，重新界定领域边界，对模块进行服务整合，对系统进行合并。❷而去层次化，则是去除服务层次高低之分，按服务调用最优链路提供服务请求，降低深度，以此保证系统的稳定性能。10/72什么是微服务这种单体应用比较适合于小项目，优点是：开发简单直接，集中式管理；基本不会重复开发；功能都在本地，没有分布式的管理开销和调用开销。11/72什么是微服务当然它的缺点也十分明显，特别对于互联网公司来说：❶开发效率低：所有的开发在一个项目改代码，递交代码相互等待，代码冲突不断；❷代码维护难：代码功能耦合在一起，新人不知道何从下手；❸部署不灵活：构建时间长，任何小修改必须重新构建整个项目，这个过程往往很长；❹稳定性不高：一个微不足道的小问题，可以导致整个应用挂掉；❺扩展性不够：无法满足高并发情况下的业务需求。12/72什么是微服务所以，现在主流的设计一般会采用微服务架构。其思路不是开发一个巨大的单体式应用，而是将应用分解为小的、互相连接的微服务。一个微服务完成某个特定功能，比如打车软件拆分为乘客管理和下单管理等。每个微服务都有自己的业务逻辑和适配器。一些微服务还会提供API接口给其他微服务和应用客户端使用。13/72什么是微服务14/72“微服务架构风格是一种将单个应用程序开发为一组小型服务的方法，每个小服务运行在自己的进程中，并且以轻量级机制（通常是HTTPRESTAPI）通信。这些服务是围绕业务能力建立的，并且可以由完全自动化的部署机构独立部署。这些服务的集中管理只有最低限度，可以用不同的编程语言编写并使用不同的数据存储技术。”——JamesLewisandMartinFowler.什么是微服务每个业务逻辑都被分解为一个微服务，微服务之间通过RESTAPI通信。一些微服务也会向终端用户或客户端开发API接口。但通常情况下，这些客户端并不能直接访问后台微服务，而是通过APIGateway来传递请求。APIGateway一般负责服务路由、负载均衡、缓存、访问控制和鉴权等任务。15/72什么是微服务16/72微服务特点17/72每个服务都是一个轻量级、独立和松散耦合的业务单元。每个服务都有自己的代码库，由一个小团队管理和开发。每个服务负责一部分功能或者说业务能力，并且做得很好。每个服务都可以为其选择最佳的技术栈。每个服务都有自己的DevOps计划（测试、发布、部署、扩展、集成和独立维护等自动化运维）。每个服务都部署在一个独立自给的环境中。服务通过使用定义良好的API和简单协议如基于HTTP的REST协议相互通信。每个服务负责持久化自己的数据和保持外部状态。微服务的优点18/72微服务架构有很多重要的优点。❶首先，它解决了复杂性问题。它将单体应用分解为一组服务。虽然功能总量不变，但应用程序已被分解为可管理的模块或服务。这些服务定义了明确的RPC或消息驱动的API边界。微服务架构强化了应用模块化的水平，而这通过单体代码库很难实现。因此，微服务开发的速度要快很多，更容易理解和维护。❷其次，这种体系结构使得每个服务都可以由专注于此服务的团队独立开发。只要符合服务API契约，开发人员可以自由选择开发技术。这就意味着开发人员可以采用新技术编写或重构服务，由于服务相对较小，所以这并不会对整体应用造成太大影响。微服务优点19/72❸第三，微服务架构可以使每个微服务独立部署。开发人员无需协调对服务升级或更改的部署。这些更改可以在测试通过后立即部署。所以微服务架构也使得CI（ContinuousIntegration）／CD（ContinuousDelivery和ContinuousDeployment）成为可能。❹最后，微服务架构使得每个服务都可独立扩展。我们只需定义满足服务部署要求的配置、容量、实例数量等约束条件即可。微服务带来的挑战实际上并不存在银弹，微服务架构也会给我们带来新的问题和挑战。❶其中一个就和它的名字类似，微服务强调了服务大小，但实际上这并没有一个统一的标准。有些开发者主张10-100行代码就应该建立一个微服务。虽然建立小型服务是微服务架构崇尚的，但要记住，微服务是达到目的的手段，而不是目标。微服务的目标是充分分解应用程序，以促进敏捷开发和持续集成部署。❷微服务的另一个主要缺点是微服务的分布式特点带来的复杂性。开发人员需要基于RPC或者消息实现微服务之间的调用和通信，而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的相当棘手。20/72微服务带来的挑战❸微服务的另一个挑战是：分区的数据库体系和分布式事务。更新多个业务实体的业务交易相当普遍。这些类型的事务在单体应用中实现非常简单，因为单体应用往往只存在一个数据库。但在微服务架构下，不同服务可能拥有不同的数据库。❹微服务架构对测试也带来了很大的挑战。传统的单体WEB应用只需测试单一的RESTAPI即可，而对微服务进行测试，需要启动它依赖的所有其他服务。这种复杂性不可低估。21/72微服务带来的挑战❺微服务的另一大挑战是跨多个服务的更改。比如在传统单体应用中，若有A、B、C三个服务需要更改，A依赖B，B依赖C。我们只需更改相应的模块，然后一次性部署即可。但是在微服务架构中，我们需要仔细规划和协调每个服务的变更部署。我们需要先更新C，然后更新B，最后更新A。部署基于微服务的应用也要复杂得多。单体应用可以简单的部署在一组相同的服务器上，然后前端使用负载均衡即可。每个应用都有相同的基础服务地址，例如数据库和消息队列。22/72微服务带来的挑战而微服务由不同的大量服务构成。每种服务可能拥有自己的配置、应用实例数量以及基础服务地址。这里就需要不同的配置、部署、扩展和监控组件。此外，我们还需要服务发现机制，以便服务可以发现与其通信的其他服务的地址。因此，成功部署微服务应用需要开发人员有更好地部署策略和高度自动化的水平。23/72微服务系统适合的场景大型的前后分离的复杂业务系统后端，业务越复杂，越需要我们合理的设计和划分，长期的维护成本会非常高，历史包袱也很重，这个问题后面会详谈。变化发展特别快的创新业务系统，业务快，就意味着天天要“拥抱变化”，每一块的业务研发都要被业务方压的喘不过气，不做拆分、自动化。一方面研发资源永远不够用，活永远干不完，另一方面不停的在给系统打补丁，越来质量越低，出错的可能性也越来越大。规划中的新大型业务系统，如果有能力一开始就应该考虑做微服务，而不是先做单体，还是发展到一定的阶段再做改造，改造一定是伤筋动骨的大手术。虽然我们可以采取一些策略做得更平滑，但是成本还是比较高的。24/72微服务系统适合的场景敏捷自驱的小研发团队，拥抱新技术，可以直接用微服务做系统。不断的通过快速迭代、持续交付，经过一定时间的尝试和调整，形成自己的微服务实践经验，这样在团队扩大时可以把好的经验复制到更大的团队。25/72微服务系统适合的场景反过来，以下几类系统，不太适合一开始就做微服务：小团队，技术基础较薄弱，创业初期或者团队新做的快速原型。这个时候做微服务的收益明显比单体要低，快速把原型做出来怎么方便怎么来，用团队最熟悉的技术栈。流量不高，压力小，业务变化也不大，单体能简单搞定的，就可以先不考虑微服务，不考虑分布式，因为分布式和微服务带来的好处，可能还不足以抵消复杂性增加带来的成本。26/72微服务系统适合的场景对延迟很敏感的低延迟高并发系统，低延迟的秘诀就是离IO能多远就多远，离CPU能多近就多近。分布式和微服务，导致增加了网络跳数，延迟就没法降低。技术导向性的系统，技术产品，这类产品跟业务系统不同，常规的业务系统研发方法不是太适合。27/72Agenda什么是微服务如何拆解服务微服务的关键技术微服务的设计模式微服务项目实战28/72如何拆解服务与传统的架构技术相比，服务的切分上有比较大的区别。SOA原本是以一种“集成”技术出现的，很多技术方案是将原有企业内部服务封装为一个独立进程，这样新的业务开发就可重用这些服务，这些服务很可能是类似供应链、CRM这样的非常大的颗粒。而微服务这个“微”，就说明了他在切分上有讲究，不妥协。无数的案例证明，如果你的切分是错误的，那么你得不到微服务承诺的“低耦合、升级不影响、可靠性高”之类的优势，而会比使用Monolithic有更多的麻烦。29/72如何拆解服务不拆分存储的微服务是伪服务：在实践中，我们常常见到一种架构，后端存储是全部和在一个数据库中，仅仅把前端的业务逻辑拆分到不同的服务进程中。本质上和一个Monolithic一样，只是把模块之间的进程内调用改为进程间调用，这种切分不可取，违反了分布式第一原则，模块耦合没有解决，性能却受到了影响。微服务的“Micro”这个词并不是越小越好，而是相对SOA那种粗粒度的服务，我们需要更小更合适的粒度，这种Micro不是无限制的小。30/72如何拆解服务如果我们将两路（同步）通信与小/微服务结合使用，并根据比如“1个类=1个服务”的原则，那么我们实际上回到了使用CORBA、J2EE和分布式对象的20世纪90年代。遗憾的是，新生代的开发人员没有使用分布式对象的经验，因此也就没有认识到这个主意多么糟糕。他们正试图重复历史，只是这次使用了新技术，比如用HTTP取代了RMI或IIOP。31/72微服务和DDD微服务无疑是一种以领域为中心的架构，其中每个服务边界都应该对应于领域。一个简单的图书管理系统肯定无需微服务架构。既然采用了微服务架构，那么面对的问题空间必然是比较宏大。比如整个电商、CRM。如何拆解服务呢？使用什么样的方法拆解服务？业界流行1个类=1个服务、1个方法=1个服务、2Pizza团队（团队保持在两个比萨能让队员吃饱的小规模的概念）、2周能重写完成等方法，但是这些都缺乏实施基础。我们必须从一些软件设计方法中寻找，面向对象和设计模式适用的问题空间是一个模块，而函数式编程的理念更多的是在代码层面的微观上起作用。32/72微服务和DDDEricEvans的《领域驱动设计》这本书对微服务架构有很大借鉴意义，这本书提出了一个能将一个大问题空间拆解分为领域和实体之间的关系和行为的技术。目前来说，这是一个最合理的解决拆分问题的方案，透过限界上下文，我们能将实现细节封装起来，让BC都能够实现SRP原则。而每个微服务正是BC在实际世界的物理映射，符合BC思路的微服务互相独立松耦合。微服务架构是一件好事，逼着大家关注设计软件的合理性，如果原来在Monolithic中领域分析、面向对象设计做不好，换微服务会把这个问题成倍的放大。33/72微服务和DDD从单体架构开始，到分布式架构设计、微服务架构，再到现在领域驱动设计，作为实践微服务的架构师，思想上又有什么变化？每个程序员心里都住一个大侠，金庸《笑傲江湖》里有气宗和剑宗之分，什么是剑宗？这就像是剑招、招数，如Spring、SpringBoot、SpringCloud，还有Tomcat、Netty、Serviceless等。这些技术、中间件、框架等就像脚手架一样可以帮助我们提高效率。34/72微服务和DDD但是，我们是否需要出现一个新技术就学习一个技术呢？而这就让人联想到了气宗，它就像是通过对内在规律的掌握，打通任督二脉，实现融会贯通，正如《九阳神功》所说：他强任他强，清风拂山岗，我自一口真气足。如Kafka、Flink、HBase等分区可用性保障的设计思想都是基于BigTable的分区复制策略。35/72微服务和DDD正是重心由外到内的转变，现在系统架构的发展，很多系统架构的复杂度，已经不是简简单单通过引入一些新技术或框架，就能降低系统复杂的。它需要大大的提前对风险、问题、隐患的预知，做到未雨绸缪。当拿到一个需求的时候，❶首先考虑的是要解决什么问题，它的问题域是什么，而不是先考虑用哪种技术去实现或解决这个问题，这是本末倒置的处理方法。从领域驱动设计的角度来看，需求首先是问题域，属于业务边界的事情，梳理了解要实现什么功能和需求。❷然后再外延到工作边界，确认团队合作的方式，因为很多需求都可能需要跨团队合作的，❸最后才会到应用边界，即技术实现的解决问题领域。36/72微服务和DDD下图是一个典型的洋葱头模型，它的思想就是阐述了从内到外的思考过程。然后，现实工作中，经常有人从外往内去考虑问题。A君有这样的的经历，一次是数据异构的方案，之前是采用Storm，后来Flink开始流行，A君就将业务切换到了Flink。但是对于Flink的调优不到位，从而影响了系统稳定性。37/72微服务和DDD还有一次是之前搜索用Solr，后来ES开始流行，就像切到ES，但是ES和Solr两套搜索引擎的搜索排序结果是不一样的，最后，我们只能“玷污”了业务。其实，这都是不太对的。《架构整洁之道》也提到：良好的架构设计应该尽可能地允许用户推迟和延后决定采用什么框架、数据库、Web服务以及其他与环境相关的工具。理解领域驱动设计，需求或问题它开始于一个领域意愿，由领域专家和交付团队一起，输出统一语言和领域知识。38/72微服务和DDD

39/72微服务和DDD采用领域驱动设计的六边形架构绘制了一张交易系统的领域边界图（上图）。U/D（Upstream-Downstream）代表上游和下游，P/S（Publish-Subscribe）表示发布和订阅。这个图还不算完整，因为领域业务逻辑是要为端服务的，而通过对领域的梳理，可以通用的支持很多端。即表达为领域有界，端无界。最终，每个限界上下文即是微服务。40/72微服务拆解四部曲系统如何从0到1，从1到2，从2到100，在具体实践微服务的过程并不容易。首先，考虑的第一个问题是：微服务是什么？其实，微服务是一个动作：拆。说到拆，就涉及到两个问题，第一，怎么拆？第二，拆到什么程度。第一个问题，关于怎么拆，需要关注两个层面。一是发版速度，如商品、交易、促销等不同领域的迭代速度和开发速度是不一致的，所以，应该拆分到不同的领域否则，就可能耦合在一起，A上线B必须跟着一起上，这可能就应该合并到一起。41/72微服务拆解四部曲另一个是协同，每个系统后面对应不同的研发团队，一个项目往往需要几个团队分工协作，那么系统拆分必然导致团队协作的成本。所以拆分系统同样也是拆分团队，要考虑协作沟通所带来的成本。第二个问题，拆到什么程度。其实，已经有很多人对微服务进行了定义，其中有最重要的两点：一是微服务或一组微服务，应该是一套独立部署运行的服务，二是微服务所依赖的数据资源应该是彼此间相互独立隔离部署的。其实，拆只是实践微服务的开始，要搭建整体的微服务框架还要进行四部曲：拆分、服务化、高可用、隔离。42/72微服务拆解四部曲43/72微服务拆解四部曲44/72（1）服务拆分微服务讲究拆分，那么多微才是微，以及怎么才是比较合理的拆分。在架构设计领域，有一个大家都在讲的著名定律：康威定律。可以理解为：一个系统架构的组织关系是和团队的组织关系相匹配的。如交易系统会对应一个交易系统的研发团队，商品系统会对应一个商品系统的研发团队，这种职责明确的组织结构会使得系统开发更高效。康威定律指出：你的组织是什么样子的，最终这个组织信息系统肯定也是相同样子。效率高的组织，系统效率自然也高。微服务拆解四部曲45/72拆分可以分为系统拆分、功能拆分和读写拆分。如一个单体系统中，按照用户的交互场景看，❶门户首页可以拆分为前台系统，❷类目、商品、搜索等功能可以拆分到商品中心，❸订单、结算、发票等功能则可以拆分到交易中心。这就是简单的系统拆分和功能拆分。而有些功能较为特殊，如商详页，在读取时需要聚合读取，所以又可以进行读写拆分。微服务拆解四部曲46/72（2）服务化微服务首先需要有微服务基础设施，没有微服务基础设施，实践微服务就是一场灾难。以SOA落地方式为例，SOA落地方式主要有：分布式服务化和集中式管理（ESB），分布式服务化的技术手段有Dubbo或SpringCloud等，必须有整套的如服务发现、服务订阅、服务监控、服务追踪、服务日志等微服务基础设置，才能进行微服务架构。不能简单只有P2P的服务调用就开始服务化，那是不现实的。微服务拆解四部曲47/72（3）服务治理当服务拆分的设计方案确认完毕，而服务化的基础设施也部署到位，那么系统往往一下子就会突然发布出成百上千个服务接口，就像一个网络一样，每个服务或微服务就像网中的一个节点，彼此之间关联和联系。但是，服务网络应该被设计成为一个有向无环图，否则，就是一团麻。譬如开始的时候，只是A调用B。但随着业务发展，需要修改，但是因为对A不了解，就加个环节B调用A，如此形成了环形调用，不仅逻辑复杂了，还降低了稳定和性能。这里的服务治理不是讲中间件团队的服务治理，如超时优化、启动优化等，而是作为应用平台对服务的治理。微服务拆解四部曲48/72服务治理又分为三个阶段：服务梳理、服务界定和服务编排。❶所谓服务梳理就是梳理系统对外开放的服务化接口，包括服务的provider和consumer，以及服务分组、动态路由等依赖的梳理。❷然后对拆散的服务进行归类、界定，确定服务领域从属性，依据领域模型重新界定服务边界。❸最后通过服务迁移、切换，对同一领域的服务接口进行服务整合，提供统一的服务出口，实现服务编排。微服务拆解四部曲49/72总结一下看从拆分到服务化的过程，就是将原来一个整体的服务打碎，碎成一块一块的零碎服务，然后再对服务重新归类、整合，形成一个一个新领域的、独立的服务。如单体架构就像一个宏伟的城堡，如果相对其中一个点进行调整和改造，那么可能面临着牵一发而动全身的风险微服务化就是以一系列小的服务去支撑一个应用的方法论。简明扼要的说，就是：分而治之。微服务拆解四部曲50/72（4）服务高可用服务拆分并服务化之后，是不是就完事了，不！真正的微服务实践才刚刚开始，简单提供了一个接口，是没有意义的，它必须具备高可用、高性能、高并发的三高特性，尤以高可用最为重要。保障服务高可用的方法有很多，如数据异构、多级缓存、超时与重试、熔断、异步并发、降级、限流、消息队列、压测与预案等。重点说下数据异构，所谓数据异构，就是将通过顺序消费或并发消费的方式，订阅MySQL数据库的binlog；然后通过消息，如Kafka等MQ方式，异地存储到缓存或其它数据源中，如Redis、ElasticSearch等。数据异构现在被普通使用，实现数据聚合，形成数据闭环。微服务拆解四部曲51/72微服务拆解四部曲52/72（5）服务隔离隔离也是服务拆分的一种，为什么单独讲？因为服务拆分、服务化、服务治理和服务高可用都是在事前或事中可以做的。然而，有些系统已经成了某个样子，那么我们接收时，首先能做到的就是迅速对系统进行隔离，保证业务之间不互相影响。具体实践包括：进程线程隔离、集群/机房隔离、读写隔离、动静隔离、爬虫/热点隔离等。微服务拆解四部曲53/72其实，每个系统的微服务架构演进道路各不相同，所以，实践微服务不能一板一眼原封照抄，而是要根据自己的业务特征，合理的裁剪，找到合适落地方案。总结一句话，那就是：因需而变。虽然微服务的路径是不一样的，但方向是相同的。再次回顾微服务的架构演进历程，你会发现，从单体架构开始进行拆分，形成微服务之后，又因为各种这样的原因，很多微服务架构又在进行合并，现在领域驱动设计来了，又开始重新拆分。真可谓：话说天下大势，分久必合，合久必分。Agenda什么是微服务如何拆解服务微服务的关键技术微服务的设计模式微服务项目实战54/72微服务的关键技术-服务治理以一般的订单系统为例，如果将用户微服务和商品微服务所在的IP地址和端口号硬编码到订单微服务中，会存在非常多的问题，其中，最明显的问题有三个，如下所示。1）如果用户微服务和商品微服务的IP地址或者端口号发生了变化，则订单微服务将变得不可用，需要对同步修改订单微服务中调用用户微服务和商品微服务的IP地址和端口号。2）如果系统中提供了多个用户微服务和商品微服务，则无法实现微服务的负载均衡功能。55/72微服务的关键技术-服务治理3）如果系统需要支持更高的并发，需要部署更多的用户微服务和商品微服务以及订单微服务。如果将用户微服务和商品微服务的IP地址和端口硬编码到订单微服务，则后续的维护会变得异常复杂。所以，在微服务开发的过程中，需要引入服务治理功能，实现微服务之间的动态注册与发现。如果系统采用了微服务的架构模式，随着微服务数量的不断增多，服务之间的调用关系会变得纵横交错，以纯人工手动的方式来管理这些微服务以及微服务之间的调用关系是及其复杂的，也是极度不可取的。所以，需要引入服务治理的功能。56/72微服务的关键技术-服务治理57/72微服务的关键技术-服务治理（1）注册中心从上面的分析可以看出，微服务实现服务治理的关键就是引入了注册中心。它是微服务架构模式中一个非常重要的组件，主要实现了服务注册与发现、服务配置和服务的健康检测等功能。服务注册与发现实现的功能一是服务注册：注册中心提供保存服务提供者和服务消费者的相关信息。二是服务发现：也可以理解为服务订阅，服务调用者也就是服务消费者，向注册中心订阅服务提供者的信息，注册中心会向服务消费者推送服务提供者的信息。58/72微服务的关键技术-服务治理常见的注册中心：能够实现注册中心功能的组件有很多，但是常用的组件大概包含：Zookeeper、Eureka、Consul、etcd、Nacos等。这里，就给大家简单介绍下这些能够实现注册中心功能的框架或组件。1）Zookeeper接触过分布式或者大数据开发的小伙伴应该都知道，Zookeeper是ApacheHadoop的一个子项目，它是一个分布式服务治理框架，主要用来解决应用开发中遇到的一些数据管理问题。例如：分布式集群管理、元数据管理、分布式配置管理、状态同步和统一命名管理等。在高并发环境下，也可以通过Zookeeper实现分布式锁功能。59/72微服务的关键技术-服务治理2）EurekaEureka是Netflix开源的SpringCloud中支持服务注册与发现的组件，但是后来闭源了。3）NacosNacos是阿里巴巴开源的一款更易于构建云原生应用的支持动态服务发现、配置管理和服务管理的平台。其提供了一组简单易用的特性集，能够快速实现动态服务发现、服务配置、服务元数据及流量管理60/72微服务的关键技术-服务网关当一个系统使用分布式、微服务架构后，系统会被拆分为一个个小的微服务，每个微服务专注一个小的业务。那么，客户端如何调用这么多微服务的接口呢？如果不做任何处理，没有服务网关，就只能在客户端记录下每个微服务的每个接口地址，然后根据实际需要去调用相应的接口。61/72微服务的关键技术-服务网关这种直接使用客户端记录并管理每个微服务的每个接口的方式，存在着太多的问题。比如，这里列举几个常见的问题。由客户端记录并管理所有的接口缺乏安全性。由客户端直接请求不同的微服务，会增加客户端程序编写的复杂性。涉及到服务认证与鉴权规则时，需要在每个微服务中实现这些逻辑，增加了代码的冗余性。客户端调用多个微服务，由于每个微服务可能部署的服务器和域名不同，存在跨域的风险。当客户端比较多时，每个客户端上都管理和配置所有的接口，维护起来相对比较复杂。62/72微服务的关键技术-服务网关1）引入API网关API网关，其实就是整个系统的统一入口。网关会封装微服务的内部结构，为客户端提供统一的入口服务，同时，一些与具体业务逻辑无关的通用逻辑可以在网关中实现，比如认证、授权、路由转发、限流、监控等。引入API网关后，如下所示。63/72微服务的关键技术-服务网关2）主流的API网关当系统采用分布式、微服务的架构模式后，API网关就成了整个系统不可分割的一部分。业界通过不断的探索与创新，实现了多种API网关的解决方案。目前，比较主流的API网关有：Nginx+Lua（luːə）、Kong、Zuul、ApacheShenyu、SpringCloudGateway。64/72微服务的关键技术-服务容错当一个系统的架构设计采用微服务架构模式时，会将庞大而复杂的业务拆分成一个个小的微服务，各个微服务之间以接口或者RPC的形式进行互相调用。在调用的过程中，就会涉及到网路的问题，再加上微服务自身的原因，例如很难做到100%的高可用等。如果众多微服务当中的某个或某些微服务出现问题，不可用或者宕机了，那么其他微服务调用这些微服务的接口时就会出现延迟。如果此时有大量请求进入系统，就会造成请求任务的大量堆积，甚至会造成整体服务的瘫痪。65/72微服务的关键技术-服务容错服务容错在一定程度上就是尽最大努力来兼容错误情况的发生，因为在分布式和微服务环境中，不可避免的会出现一些异常情况。我们在设计分布式和微服务系统时，就要考虑到这些异常情况的发生，使得系统具备服务容错能力。常见的服务错误方案包含：服务限流、服务隔离、服务超时、服务熔断和服务降级等。66/72微服务的关键技术-服务容错（1）服务限流服务限流就是限制进入系统的流量，以防止进入系统的流量过大而压垮系统。其主要的作用就是保护服务节点或者集群后面的数据节点，防止瞬时流量过大使服务和数据崩溃（如前端缓存大量实效），造成不可用；还可用于平滑请求。67/72微服务的关键技术-服务容错具体到我们的交易系统中，应该在哪些地方做限流呢？主要就是对接口做限流，而我们的接口可以分为几大类：管理端API、客户端API、开放API、服务内部API。管理端API基本不会有突发流量的产生，所以也没必要做限流。客户端API和开放API则需要做限流，但两者的限流规则应该不一样，对开放API的限流规则应该严格一些，因为更容易被攻击。68/72微服务的关键技术-服务容错服务内部API在目前阶段也可以不做限流，一般微服务的规模比较大，某些服务的调用方比较多的时候需要做限流；或者其他一些场景导致下游出现突发流量的时候，比如上游调用方多线程并发跑定时任务调用下游服务的接口。这种情况下为了防止接口被过度调用，就需要对每个调用方进行细粒度的访问限流。69/72微服务的关键技术-服务容错（2）服务隔离服务隔离有点类似于系统的垂直拆分，就按照一定的规则将系统划分成多个服务模块，并且每个服务模块之间是互相独立的，不会存在强依赖的关系。如果某个拆分后的服务发生故障后，能够将故障产生的影响限制在某个具体的服务内，不会向其他服务扩散，自然也就不会对整体服务产生致命的影响。互联网行业常用的服务隔离方式有：线程池隔离和信号量隔离。70/72微服务的关键技术-服务容错（3）服务超时整个系统采用分布式和微服务架构后，系统被拆分成一个个小服务，就会存在服务与服务之间互相调用的现象，从而形成一个个调用链。形成调用链关系的两个服务中，主动调用其他服务接口的服务处于调用链的上游，提供接口供其他服务调用的服务处于调用链的下游。服务超时就是在上游服务调用下游服务时，设置一个最大响应时间，如果超过这个最大响应时间下游服务还未返回结果，则断开上游服务与下游服务之间的请求连接，释放资源。71/72微服务的关键技术-服务容错（4）服务熔断服务熔断主要是应对服务雪崩的一种自我保护机制。当下游的目标服务因为某种原因突然变得不可用或响应过慢，上游服务为了保证自己整体服务的可用性，不再继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。服务熔断一般情况下会有三种状态：关闭、开启和半熔断。最开始处于closed状态，一旦检测到错误率到达一定阈值，便转为open状态；这时候会有个resettimeout，到了这个时间了，会转移到halfopen状态；尝试放行一部分请求到目标服务，一旦检测成功便回归到closed状态，即恢复服务。72/72微服务的关键技术-服务容错（5）服务降级服务降级，说白了就是一种服务托底方案。如果服务无法完成正常的调用流程，就使用默认的托底方案来返回数据。例如，在商品详情页一般都会展示商品的介绍信息，一旦商品详情页系统出现故障无法调用时，会直接获取缓存中的商品介绍信息返回给前端页面。73/72微服务的关键技术-服务容错从概念上来说，所谓的服务降级，是当服务器压力剧增的情况下，根据当前业务情况及流量对一些服务和页面进行策略性的屏蔽或降低服务质量，以此释放服务器资源以保证核心任务的正常运行。从使用场景来说，当整个微服务架构整体的负载超出了预设的上限阈值或即将到来的流量预计将会超过预设的阈值时，为了保证重要或基本的服务能正常运行，我们可以将一些不重要或不紧急的服务或任务进行服务的延迟使用或暂停使用。74/72微服务的关键技术-服务容错服务降级的方式或策略其实有多种，除了限流和熔断，常用的还有以下这些：关闭次要服务：在服务压力过大时，关闭非核心功能的服务，避免核心功能被拖垮。比如，淘宝双11活动当天，订单量激增，为了保证核心的交易业务的高可用，就会暂时关闭非核心的退货服务。丢弃部分请求：对于一些老请求——即从接收到处理的时间已经超过了一定时间（比如1s）的请求，可以直接丢弃。还可以根据请求的优先级，有选择性地丢弃那些优先级低的请求。或者随机丢弃一定比例的请求。读降级：对于读一致性要求不高的场景，在服务和数据库压力过大时，可以不读数据库，降级为只读缓存数据，以这种方式来减小数据库压力，提高服务的吞吐量。75/72微服务的关键技术-服务容错写降级：在服务压力过大时，可以将同步写转为异步写，来减小服务压力并提高吞吐量。既然把同步改成了异步也就意味着降低了数据一致性，保证数据最终一致即可。屏蔽写入：很多高并发场景下，查询请求都会走缓存，这时数据库的压力主要是写入压力。所以对于某些不重要的服务，在服务和数据库压力过大时，可以关闭写入功能，只保留查询功能，这样可以明显减小数据库压力。数据冗余：服务调用者可以冗余它所依赖服务的数据。当依赖的服务故障时，服务调用者可以直接使用冗余数据。76/72Agenda什么是微服务如何拆解服务微服务的关键技术微服务的设计模式微服务项目实战77/72微服务的设计模式-独享数据库当一家公司将大型单体系统替换成一组微服务，首先要面临的最重要决策是关于数据库。单体架构会使用大型中央数据库。即使转移到微服务架构许多架构师仍倾向于保持数据库不变。虽然有一些短期收益，在大规模系统中，微服务将在数据库层严重耦合，整个迁移到微服务的目标都将面临失败。更好的方法是为每个微服务提供自己的数据存储，这样服务之间在数据库层就不存在强耦合。这里使用数据库这一术语来表示逻辑上的数据隔离，也就是说微服务可以共享物理数据库。但应该使用分开的数据结构、集合或者表，这还将有助于确保微服务是按照领域驱动设计的方法正确拆分的。78/72微服务的设计模式-独享数据库79/72微服务的设计模式-独享数据库80/72优点数据由服务完全所有。服务的开发团队之间耦合度降低。缺点服务间的数据共享变得更有挑战性。在应用范围的保证ACID事务变得困难许多。细心设计如何拆分单体数据库是一项极具挑战的任务。微服务的设计模式-独享数据库81/72何时使用独享数据库在大型企业应用程序中。当团队需要完全把控微服务以实现开发规模扩展和速度提升。何时不宜使用独享数据库在小规模应用中。如果是单个团队开发所有微服务。微服务的设计模式-事件源82/72在微服务架构中，特别使用独享数据库时，微服务之间需要进行数据交换。对于弹性高可伸缩的和可容错的系统，它们应该通过交换事件进行异步通信。在这种情况，可能希望进行类似：更新数据库并发送消息这样的原子操作，如果在大数据量的分布式场景使用关系数据库，将无法使用两阶段锁协议（2PL），因为它无法伸缩。而NoSQL数据库因为大多不支持两阶段锁协议甚至无法实现分布式事务。微服务的设计模式-事件源83/72在这些场景，可以基于事件的架构使用事件源模式。在传统数据库中，直接存储的是业务实体的当前“状态”，而在事件源中任何“状态”更新事件或其他重要事件都会被存储起来，而不是直接存储实体本身。这意味着业务实体的所有更改将被保存为一系列不可变的事件。因为数据是作为一系列事件存储的，而非直接更新存储，所以各项服务可以通过重放事件存储中的事件来计算出所需的数据状态。微服务的设计模式-事件源84/72微服务的设计模式-事件源85/72优点为高可伸缩系统提供原子性操作。自动记录实体变更历史，包括时序回溯功能。松耦合和事件驱动的微服务。缺点从事件存储中读取实体成为新的挑战，通常需要额外的数据存储（CQRS模式）。系统整体复杂性增加了，通常需要领域驱动设计。系统需要处理事件重复（幂等）或丢失。变更事件结构成为新的挑战。微服务的设计模式-事件源86/72何时使用事件源使用关系数据库的、高可伸缩的事务型系统。使用NoSQL数据库的事务型系统。弹性高可伸缩微服务架构。典型的消息驱动或事件驱动系统（电子商务、预订和预约系统）。何时不宜使用事件源使用SQL数据库的低可伸缩性事务型系统。在服务可以同步交换数据（例如，通过API）的简单微服务架构中。微服务的设计模式-CQRS87/72如果我们使用事件源，那么从事件存储中读取数据就变得困难了。要从数据存储中获取实体，我们需要处理所有的实体事件。有时我们对读写操作还会有不同的一致性和吞吐量要求。此时，我们可以使用CQRS模式。在其简单形式中，不同实体或ORM模型被用于读写操作。在其高级形式中，会有不同的数据存储用于读写操作。高级的CQRS通常结合事件源模式。根据不同情况，会使用不同类型的写数据存储和读数据存储。写数据存储是“记录的系统”，也就是整个系统的核心源头。微服务的设计模式-CQRS88/72微服务的设计模式-CQRS89/72对于读频繁的应用程序或微服务架构，OLTP数据库（任何提供ACID事务保证的关系或非关系数据库）或分布式消息系统都可以被用作写存储。对于写频繁的应用程序（写操作高可伸缩性和大吞吐量），需要使用写可水平伸缩的数据库（如全球托管的公共云数据库）。标准化的数据则保存在写数据存储中。对搜索（如ElasticSearch）或读操作（KV数据库）进行优化的非关系数据库常被用作读存储。许多情况会在需要SQL查询的地方使用读可伸缩的关系数据库。非标准化和特殊优化过的数据则保存在读存储中。数据是从写存储异步复制到读存储中的，所以读存储和写存储之间会有延迟，但最终是一致的。微服务的设计模式-CQRS90/72优点在事件驱动的微服务中数据读取速度更快。数据的高可用性。读写系统可独立扩展。缺点读数据存储是弱一致性的（最终一致性）。整个系统的复杂性增加了，混乱的CQRS会显着危害整个项目。微服务的设计模式-CQRS91/72何时使用CQRS在高可扩展的微服务架构中使用事件源。在复杂领域模型中，读操作需要同时查询多个数据存储。在读写操作负载差异明显的系统中。何时不宜使用CQRS在没有必要存储大量事件的微服务架构中，用事件存储快照来计算实体状态是一个更好的选择。在读写操作负载相近的系统中。微服务的设计模式-Saga如果微服务使用独享数据库，那么通过分布式事务管理一致性是一个巨大的挑战。你无法使用传统的两阶段提交协议，因为它要么不可伸缩（关系数据库），要么不被支持（多数非关系数据库）。但还是可以在微服务架构中使用Saga模式实现分布式事务。Saga是1987年开发的一种古老模式，是关系数据库中关于大事务的一个替代概念。92/72微服务的设计模式-Saga但这种模式的一种现代变种对分布式事务也非常有效。Saga模式是一个本地事务序列，其每个事务在一个单独的微服务内更新数据存储并发布一个事件或消息。Saga中的首个事务是由外部请求（事件或动作）初始化的，一旦本地事务完成（数据已保存在数据存储且消息或事件已发布），那么发布的消息或事件则会触发Saga中的下一个本地事务。93/72微服务的设计模式-Saga94/72微服务的设计模式-Saga95/72如果本地事务失败，Saga将执行一系列补偿事务来回滚前面本地事务的更改。Saga事务协调管理主要有两种形式：事件编排Choreography：分散协调，每个微服务生产并监听其他微服务的事件或消息然后决定是否执行某个动作。命令编排Orchestration：集中协调，由一个协调器告诉参与的微服务哪个本地事务需要执行。微服务的设计模式-Saga96/72优点为高可伸缩或松耦合的、事件驱动的微服务架构提供一致性事务。为使用了不支持2PC（Two-phasecommitprotocol，二阶段提交协议）的非关系数据库的微服务架构提供一致性事务。缺点需要处理瞬时故障，并且提供等幂性。难以调试，而且复杂性随着微服务数量增加而增加。微服务的设计模式-Saga97/72何时使用Saga在使用了事件源的高可伸缩、松耦合的微服务中。在使用了分布式非关系数据库的系统中。何时不宜使用Saga使用关系数据库的低可伸缩性事务型系统。在服务间存在循环依赖的系统中。微服务的设计模式-BFF98/72BFF（BackendforFrontend）架构是一种针对前端应用程序所设计的后端架构，其目的是为了满足不同的前端应用程序的需求而设计出不同的后端服务，从而提高前端应用程序的性能和灵活性。在现代商业应用开发，特别是微服务架构中，前后端应用是分离和独立的服务，它们通过API或GraphQL连接。如果应用程序还有移动App客户端，那么Web端和移动客户端使用相同的后端微服务就会出现问题。微服务的设计模式-BFF99/72因为移动客户端和Web客户端有不同的屏幕尺寸、显示屏、性能、能耗和网络带宽，它们的API需求不同。面向前端的后端模式适用于需要为特殊UI定制单独后端的场景。它还提供了其他优势，比如作为下游微服务的封装，从而减少UI和下游微服务之间的频繁通信。此外，在高安全要求的场景中，BFF为部署在DMZ网络中的下游微服务提供了更高的安全性。微服务的设计模式-BFF100/72何时使用BFF如果应用程序有多个含不同API需求的UI。出于安全需要，UI和下游微服务之间需要额外的层。如果在UI开发中使用微前端。何时不宜使用BFF如果应用程序虽有多个UI，但使用的API相同。如果核心微服务不是部署在DMZ网络中。微服务的设计模式-Strangler101/72如果想在运行中的项目中使用微服务架构，我们需要将遗留的或现有的单体应用迁移到微服务。将现有的大型在线单体应用程序迁移到微服务是相当有挑战性的，因为这可能破坏应用程序的可用性。一个解决方案是使用Strangler模式。Strangler模式意味着通过使用新的微服务逐步替换特定功能，将单体应用程序增量地迁移到微服务架构。微服务的设计模式-Strangler102/72此外，新功能只在微服务中添加，而不再添加到遗留的单体应用中。然后配置一个Facade（API网关）来路由遗留单体应用和微服务间的请求。当某个功能从单体应用迁移到微服务，Facade就会拦截客户端请求并路由到新的微服务。一旦迁移了所有的功能，遗留单体应用程序就会被“扼杀（Strangler）”，即退役。微服务的设计模式-Strangler103/72微服务的设计模式-Strangler104/72何时使用Strangler将大型后端单体应用程序的增量迁移到微服务。何时不宜使用Strangler如果后端单体应用很小，那么全量替换会更好。如果无法拦截客户端对遗留的单体应用程序的请求。Agenda什么是微服务如何拆解服务微服务的关键技术微服务的设计模式微服务项目实战105/72微服务项目实战PiggyMetrics是一款简单的财务顾问应用程序，旨在使用SpringBoot、SpringCloud和Docker演示微服务架构模式。PiggyMetrics被分解为三个核心微服务。所有这些都是围绕特定业务域组织的可独立部署的应用程序。106/72微服务项目实战107/72微服务项目实战（1）Accountservice包含常规输入逻辑和验证：收入/支出项目、储蓄和帐户设置。108/72微服务项目实战（2）Statisticsservice对主要统计参数执行计算，并捕获每个帐户的时间序列。数据点包含标准化为基础货币和时间段的值。这些数据用于跟踪账户生命周期内的现金流动态。109/72微服务项目实战（3）Notificationservice存储用户联系信息和通知设置（提醒、备份频率等）。定时工作人员从其他服务收集所需信息，并向订阅的客户发送电子邮件。110/72每个微服务都有自己的数据库，因此无法绕过API直接访问持久性数据；MongoDB被用作每个服务的主数据库；所有服务都通过RestAPI相互通信。

PiggyMetrics的架构111/72PiggyMetrics的架构（1）配置服务SpringCloudConfig是一种用于分布式系统的横向可扩展的集中式配置服务。它使用了一个可插入的存储库层，目前支持本地存储、Git和Subversion。在这个项目中，我们将使用nativeprofile，它只需从本地类路径加载配置文件。我们可以在配置服务资源中看到shared目录。现在，当Notification服务请求其配置时，Config服务会使用shared/Notification-service.yml