第一章，直面响应式微服务架构

    sdubaspringBo等框架为代表的分布式服务调用和治理工具的大行其道，以及dockercoberate等容器技术的日渐成熟，微服务架构microservicearchitecture毫无疑问是近年来最热门的一种服务化架构模式。所谓微服务，就是一些具有足够小的力度。能够相互协作且自制的服务体系。注意，每个微服务都比较简单，仅关注于完成一个业务功能，所以具备技术、业务和组织上的优势。另外，随着SPRING5的正式发布，我们迎来了响应式编程reactiveprogramming的全新发展时期。SPRING5内嵌了响应式web框架。是数据访问、响应式消息通信等多种响应式组件，从而极大地简化了响应式应用程序的开发过程和难度。本书作为全书的开篇，将对微服务架构和响应式系统reactivesystem的核心概念做简要介绍，同时给出两者之间的整合点及如何构建响应式微服务架构。在本章最后，我们也会给出全书的组织架构，以便读者能够总览全书。小智系统核心概念在本节中，我们将带领大家进入响应式系统的世界。为了让大家更好的理解小英式编程和小英式系统的核心概念，我们将先从传统编程方法出发，逐步引出小英式编程方法。同时，我们还将通过小英式官宣reactive。了解响应式系统的基本特性和设计理念，从传统编程方法到小英式编程方法。在电商系统中，订单查询是一个典型的业务场景，用户可以通过多种维度获取自己已下订单的列表信息和各个订单的明细信息。我们就通过订单查询这一特定场景来分析传统编程。和响应式编程方法之间的区别，订单查询方法的传统方法。在典型的三层架构中，图。一个展示了基于传统实现方法的订单查询场景时序图。一般用户会使用前端组件所提供的操作入口进行订单查询，然后该操作入口会调用后台服务的服务层，服务层在调用数据访问层进而访问数据库，数据从数据库获取之后逐层返回，最后显示在包括前端服务或用户操作界面在内的前端组件上。现在图一-一所展示的整个过程中，前端组件通过主动拉取的方式从数据库中获取数据，如果用户不触发前端操作，那么就无法获取数据库中的数据状态，也就是说前端组件对数据库的任意数据变更一无所知。订单查询场景的响应式方法主动拉取数据的方式在某些场景下可以运作的很好，但如果我们希望数据库中的一些数据有变化就收到前端组件，这种方式就不是很合理。这种场景下，我们希望前端组件通过注册机制。获取数据变更的事件，图一-二展示了这一过程，图一-二中，我们并不是直接访问数据库来获取数据，而。oursimilarorderchangedevent事件。当订单数据发生任何变化时，系统就会生成这一事件，然后通过一定的方式传播出来，而订阅了该事件的服务就会捕获该事件，从而通过前端组件响应该事件。的基本步骤涉及了对某个特定事件进行订阅，然后等待事件的发生。如果不需要再对该事件做出响应，我们就可以取消对事件的订阅。体现的是响应式系统中的一种变化传递。peingpationofchange思想及当数据变化之后，会像多米诺骨牌一样，导致直接和间接引用它的其他数据均发生相应变化。一般而言，生产者只负责生成并发出事界，然后消费者来监听并负责定义如何处理事件的变化传递方式。显然，这种世件连起来会形成一串数据流datastream。如果我们对数据流的每个事件能够及时做出响应，就会有效提高系统的响应能力。基于数据流是响应式系统的另一个核心特点，我们再次回到图一杠一，如果从底层数据库驱动，经过数据访问层到服务层，最后到全前端组件，这个服务访问链路全部采用响应式的编程方式，从而搭建一条能够传递变化的管道。这样一旦数据控注重调，注重的数据有空间。就能够相应的发生变化。而且当这种变化发生时，我们不需要通过各种传统调研方式来传递这种变化，而是由搭建好的数据流自动进行传递。乘法和响应式方法的对比图一杠一展示的传统方法和图一个二展示的响应式方法具有明显的差异，我们分别从处理过程、线程管理和伸缩性角度来做简要对比。处理过程传统开发过程下，我们拉取破数据的变化，这意味着我们整个过程是一种间歇性互补相关的处理过程前端组件不关心数据库中的数据是否有变化，在响应式开发过程方式下，一旦对事件进行注册，处理过程只有在数据变化时才会被触发。类似一种。push的工作方式，县程管理在传统开发方式下，县城的生命周期比较长，在县城存活的状态下，该县城所使用的资源都会被锁住，当服务器在同时处理多个线程时，就会存在资源的竞争问题。在响应式开发过程下下生成世界好。现场存活时间都很短，所以资源之间存在较少的竞争关系。伸缩性在传统开发方式下，系统伸缩性涉及的数据库和应用服务器的伸缩一般我们需要专门采用一些服务器架构和资源来应对伸缩性需求。在响应式开发方式下，因为县城的生命周期很短，同样的基础设施可以处理更多的用户请求，同时响应式的开发方式也同时支持传统开发方式下的各种伸缩性实现机制。并提供了更多的分布分布式实现选择。图一杠三展示了事件处理和系统伸缩性之间的关系。在杠三中，web的应用程序和事件处理程序显然可以分别进行伸缩，这为伸缩性实现了机制提供了更多的选择性余地。响应宣言和响应式系统如同业界的其他宣言一样，响应式宣言是一种一组设计原则，符合这些原则的系统可以认为是响应式系统。同时，响应式宣言也是一种架构风格，是一种关于分布式环境下的系统设计的搞方式，小英式系统也是具备这一架构风格的系统。响应式系统的特性响应式宣言给出的响应式系统所应该具备的特性包括及时响应性、onive。whatresidents，弹性elastic以及消息驱动messagedriver。这些特性的系统可以称为响应式系统给出的响应式宣言的图形化的描述。在图一杠四中，小牛式宣言认为小应式系统的价值在于提供及时响应性、可维护性和可扩展性。现在是就是回弹性和弹性，而实现的手段则是消息驱动。我们需要对这些名词做一一的展开。以下关于响应式系统的各个特性的描述来自于响应式宣言中文版，为了在描述上与本书的其他内容的统一，部分名称和语句做了调整。读书可以读者可以访问小林市宣言中文版官方网站获取更多的信息。其实响应信用指的是只要有可能，系统就会及时的做出响应，及时响应是可用性和实用性的基石，更加重要的是，及时响应意味着可以快速的检测问题，并用有效的对其进行处理，及时响应的系统专注于提供快速一致的响应，确立可靠的反馈。上线以。回指的是系统在实现失败的时候保持及时响应性。是通过复制、遏制、隔离以及委托来实现。失败的扩散被遏制在了每个组件内部，与其他组件相互隔离，从而确保系统某个部分的失败不会危及整个系统，并能独立恢复。每个组件的恢复都会被委托给了另一个内部或外部的组件。此外，必要时可以通过复制来保证高可用性，因此组建的客户端不再不再承担组建失败的处理。政使的系统在不断变化的工作负载之下，依然保持及时响应性，响应是系统可以对呃输入的速率变化做出反律反应。比如，通过增加或减少用于服务这些输入的资源分配，这意味着在设计上并没有竞争点和中央瓶颈。系统得以在组件的分片或者复制并在它们之间分布输入。通过实现相关的实时性能指标，响应式系统能够支持预测式以及响应式的伸缩算法。微档以及软件平台上实现高效的弹性。消息消息驱动指的是小应式系统依赖异步的消息传递，从而确保松口和隔离位置透明组件之间有着明确的边界，这一边界还提供了将失败作为消息委托出去的手段。使用显示的消息传递可以通过在系统中的塑造并监视消息留对时并对必要进行备压，从而实现负载管理、弹性以及流量控制。使用位置透明的消息传递作为通信的手段，使得跨机群或者单个主机使用相同的结构成分和语义来管理失败成为可能。非组赛道通信使的接收者可以只在活动时才消耗资源，从而减少系统开销。响应式的维度小应式的概念还体现在不同维度上，包括响用世界、响应压力、响应错误和响应用户。响应世界基于消息驱动机制，小应是系统可以对事件做出快速响应。应沈阳压力。的系统压力下进行灵活响应，当压力较大的时候使用更多的资源，当压力变小的时候则释放不需要的资源。想用系统可以优雅的处理错误，监控组件的可用性，并在必要时勇于组建。想要用户应是系统的确能够积极用户响应用户请求，但当消费者没有订阅世界时，就不会浪费资源进行不必要的处理。都是业务架构。目前微服架构已经成为一种主流的软件开发方法论，他把一种特定的软件应用设计的方法描述为能够独立部署的服务套件。本节将对微服务设计原理和架构做精简而全面的介绍。分布式系统与微服务架构微服务架构首先表现为一种分布式系统distributedsystem，而分布式系统是传统单块系统。moreorlesssystem的一种演进灯泡系统在软件技术发展的过程很长时间内，软件系统都表现为一种单块系统。时至今日，很多单化系统仍然在某一些行业和组织得到了开发和维护。所谓端块系统，简单的说就是把一个系统所涉及的各个组件都打包成了一个一体化的结构进行部署和运行。在JavaEE领域，这种一体化的结构很多时候就体现我一个W。二而部署和运行环境就是以talk。为各种应用服务器。单统其存在和发展的固有优势，当团队规模并不是太大的时候，一个单块应用可以由一个开发者团队进行独立维护，团队的成员能够对单块应用进行快速学习、理解和修改。为机构非常简单。同时因为单块系统的表现形式就是一个独。我。想要对他进行集中集成部署以及实现无状态集群，集群相对也比较简单。通常。通常要采用负载均衡机制并运行在该太空的多个实例就能够达到系统伸缩性的要求。但在另一方面，随着公司或者是组织业务的不断扩张、业务结构的不断变化以及用户量的不断增加，电块系统的优势已经无法适应互联网时代的快速发展，面临着越来越多的挑战，比如如何处理业务复杂度，如何防止代码腐化，如何处理团队协作问题以及如何应对系统伸缩性问题。针对以上集中式的单块系统所普遍存在的问题，基本的解决方案主要依赖于分配分布式系统的合理构建。分布系统。所谓分布式系统，就是硬件或者是软件组件分布在不同的网络计算机上，彼此通过一定的通信机制进行交互和协调系统。我们从这个定义中可以看出，分布式系统包含两个区别于单块系统的本质特征，一个是网络分布式系统，所有的组件都位于网络中，对于互联网应用而言则位于更为复杂的互联网环境中，另一个就是通信和协调。与单块系统不同，位于分布式系统的各个组件只有通过约定高效且可靠的通信机制进行相关。才成某项业务功能。这就是我们设计和实现分布式系统时首先需要考虑的两个方面。分布式相较于集中性的系统而言，具备了优势的同时，也存在一些我们不得不考虑的特性，包括但不限于网络传输的生态性、系统的异构性、数据的一致性、服务的可用性等。以上问题是分布式系统的基本特性，我们无法避免，只能够想办法进行利用和管理，这就给我们的设计和实现分布式系统提出了挑战。服务在本质上也是一种分布式系统，但在遵循通用分布特性的基础上，微服架构还表现出一定的特殊性。接下来我们将要围绕微服务架构的这些特性进行展开。微服务架构Martinfloors指出，微服务架构具有以下特点，服务组件化组件component是一种可独立替换或升级的软件单元，在日常开发的过程中，我们可能会设计和使用很多组件。这些。能于系统内部，也可能存在于系统所运行的进程之外，而服务就是一种进程外的组件。服务之间利用诸如rpcremoteprocedurecall远程过程调用的通信机制完成交互。服务组件化的主要目的就是服务可以独立部署。如果你的应用程序由一个运行在独立进程中的很多组件组成，那么对于任何一个组件的改变都会导致必须重新部署整个应用程序。但是，果你把应用程序拆分成很多服务，显然通常情况下你只需要重新部署那个改变的服务。在微服务架构中，每个服务运程的其独立的进程中，服务与服务之间采用了轻量级通信机制，互为沟通，按照业务能力的组织服务。当寻找一个把大的应用程序进行拆分的方法时候，研发过程通常都会围绕产品团队、UED团队、APP前端团队和服务端团队进行展开，这些团队也就是通常所说的职能团队functionteam。当使用这些标准对团队进行划分的时候，任何一个需求变更，无论大小都会导致跨团队协作，从而增加了沟通和协作成本。而微服务架构划分的方法有所不同，它倾向围绕业务功能的组织来分割服务，这些服务面向具体的业务结构，而不是面向某项技术能力。因此。crossfunctional的特征团队facialteam。用业、项目管理和技术研发等开发过程中要求的所有技能，每个服务都围绕着业务进行构建，并且能够被独立部署到生产类和类生产的环境。这服务集中治理的一个好处就是在单一平台上进行标准化，但采用微服务的团队更喜欢不同的标准，而集中式的系统的组件拆分成不同的服务，我们在构建这些服务的时候就会有更多的选择。对具体的某一服务而言，应该根据业务上下文选择合适的语言和工具进行构建。另一微服务架构也崇尚于对数据进行分散管理。中使用使用单一逻辑数据库进行数据持久化时，通常选择在应用的范围内使用一个数据库。然而微服务让每个服务管理自己的数据库。无论相同数据库的不同实例还是不同数据库系统基础设施自动化。许多使用微服务架构产品或者系统的团队拥有丰富的持续集成conalintegration和持续交付continuousdelivery经验。团队使用微服务架构构建软件需要更广泛依赖基础设施自动化技术。在微服务中，同样需要考虑服务容错性、设计等分布式系统所需要考虑的问题。我们对以上特点进行总结和提炼，认为微服务具有业务独立、进程隔离、团队自主、技术无关、轻量级通信以及交付独立性等微特性。服务于机床。本节在微服务架构的基础概念的基础上，简要分析服务拆分的策略和手段，同时也给出对拆分之后的服务进行集成的各种实现方法和技术体系。服务称，在微服务架构中，我们认为服务是业务能力的代表，需要围绕业务进行组织。服务拆分的关键在于正确理解物业务，识别单个服务内部的业务领域及其边界，并按边界进行拆分。所以微服务的拆分的模式本质上是基于不同的业务进行拆分。业务体现在各个功能代码中，通过确定的业务边界，并使用礼遇与界限上下文、boundarycontact和领域世界domainevent等技术手段来实现拆分。数据对微服务架构而言，同样可以认为是一种依赖关系，因为任何的业务都需要使用这个数据容器作为持久化的机制或者是数据处理的媒介。这里的数据容器不仅是关系型数据库，还泛指包括消息队列、搜索引擎以及各种。QG类的数据媒介微服务的架构存在一种说法，即我们需要微服务用到的所有资源全部嵌入到该服务中，从而确保微服务的独立性。而数据的拆分则体现在如何将集中式的中心化数据转变为个微服务各自拥有的独立数据。这部分工作同样十分具有挑战性。关于业务和数据应该先拆分谁的问题，应该是先数据库后业务代码，也可以是先业务代码后数据库感。然而，在拆分中遇到的最大挑战可能是数据层的拆分。因为在数据库的可能存在各种跨。连接、跨库连接、查询以及不同业务模块的代码和数据耦合变得非常紧密的场景，这会导致服务的拆分非常困难。因此。在分步骤上，我们更多的推荐数据库先行，数据模型能否彻底分开，很大程度上决定了微服务的边界功能是否彻底划清。服务拆分的方法根据数据系统自身的特点和运行状态，通常分为绞杀者和修缮者两种模式。绞杀者模式。pattern指的是在现有的系统外围，将新功能用新的方式构建新的服务的策略以及微服务方式逐步实现对老系统的替换，而不是直接修改原有系统。采用这种。逐渐的，新的服务就会逐渐绞杀脑的系统，对于那些规模很大又难以对现在的架构进行修改的遗留系统推荐。而小模式就如同修房或修路一样，将老旧带修缮的部分进行隔离，用新的方法对其进行单独修复，修复的同时需保证其其他部分仍能够保持系统。这种路出发修缮的模式更多的表现为一种重构技术，具体实现上可以参考Martinfloorsbranchandrestrict。之间必须要集成，而这种继承关系远比简单的API调用要复杂。不言，我们的思路是尽量采用标准化的。