s duba sprin Bo等框架为代表的分布式服务调用和治理工具的大行其道，以及docker coberate等容器技术的日渐成熟，微服务架构cro service architecture毫无疑问是近年来最热门的一种服务化架构模式。所谓微服务，就是一些具有足够小的力度。能够相互协作且自制的服务体系。注意，每个微服务都比较简单，仅关注于完成一个业务功能，所以具备技术、业务和组织上的优势。另外，随着SPRING5的正式发布，我们迎来了响应式编程reactive prorain的全新发展时期。SPRING5内嵌了响应式web框架。是数据访问、响应式消息通信等多种响应式组件，从而极大地简化了响应式应用程序的开发过程和难度。本书作为全书的开篇，将对微服务架构和响应式系统reactive syste核心概念做简要介绍，同时给出两者之间的整合点及如何构建响应式微服务架构。在本章最后，我们也会给出全书的组织架构，以便读者能够总览全书。小智系统核心概念在本节中，我们将带领大家进入响应式系统的世界。为了让大家更好的理解小英式编程和小英式系统的核心概念，我们将先从传统编程方法出发，逐步引出小英式编程方法。同时，我们还将通过小英式官宣reactive。了解响应式系统的基本特性和设计理念，从传统编程方法到小英式编程方法。在电商系统中，订单查询是一个典型的业务场景，用户可以通过多种维度获取自己已下订单的列表信息和各个订单的明细信息。我们就通过订单查询这一特定场景来分析传统编程。和响应式编程方法之间的区别，订单查询方法的传统方法。在典型的三层架构中，图。一个展示了基于传统实现方法的订单查询场景时序图。一般用户会使用前端组件所提供的操作入口进行订单查询，然后该操作入口会调用后台服务的服务层，服务层在调用数据访问层进而访问数据库，数据从数据库获取之后逐层返回，最后显示在包括前端服务或用户操作界面在内的前端组件上。现在图一-一所展示的整个过程中，前端组件通过主动拉取的方式从数据库中获取数据，如果用户不触发前端操作，那么就无法获取数据库中的数据状态，也就是说前端组件对数据库的任意数据变更一无所知。订单查询场景的响应式方法主动拉取数据的方式在某些场景下可以运作的很好，但如果我们希望数据库中的一些数据有变化就收到前端组件，这种方式就不是很合理。这种场景下，我们希望前端组件通过注册机制。获取数据变更的事件，图一-二展示了这一过程，图一-二中，我们并不是直接访问数据库来获取数据，而。our silar order chaned event事件。当订单数据发生任何变化时，系统就会生成这一事件，然后通过一定的方式传播出来，而订阅了该事件的服务就会捕获该事件，从而通过前端组件响应该事件。的基本步骤涉及了对某个特定事件进行订阅，然后等待事件的发生。如果不需要再对该事件做出响应，我们就可以取消对事件的订阅。体现的是响应式系统中的一种变化传递。pein pation of chane思想及当数据变化之后，会像多米诺骨牌一样，导致直接和间接引用它的其他数据均发生相应变化。一般而言，生产者只负责生成并发出事界，然后消费者来监听并负责定义如何处理事件的变化传递方式。显然，这种世件连起来会形成一串数据流data strea如果我们对数据流的每个事件能够及时做出响应，就会有效提高系统的响应能力。基于数据流是响应式系统的另一个核心特点，我们再次回到图一杠一，如果从底层数据库驱动，经过数据访问层到服务层，最后到全前端组件，这个服务访问链路全部采用响应式的编程方式，从而搭建一条能够传递变化的管道。这样一旦数据控注重调，注重的数据有空间。就能够相应的发生变化。而且当这种变化发生时，我们不需要通过各种传统调研方式来传递这种变化，而是由搭建好的数据流自动进行传递。乘法和响应式方法的对比图一杠一展示的传统方法和图一个二展示的响应式方法具有明显的差异，我们分别从处理过程、线程管理和伸缩性角度来做简要对比。处理过程传统开发过程下，我们拉取破数据的变化，这意味着我们整个过程是一种间歇性互补相关的处理过程前端组件不关心数据库中的数据是否有变化，在响应式开发过程方式下，一旦对事件进行注册，处理过程只有在数据变化时才会被触发。类似一种。push的工作方式，县程管理在传统开发方式下，县城的生命周期比较长，在县城存活的状态下，该县城所使用的资源都会被锁住，当服务器在同时处理多个线程时，就会存在资源的竞争问题。在响应式开发过程下下生成世界好。现场存活时间都很短，所以资源之间存在较少的竞争关系。伸缩性在传统开发方式下，系统伸缩性涉及的数据库和应用服务器的伸缩一般我们需要专门采用一些服务器架构和资源来应对伸缩性需求。在响应式开发方式下，因为县城的生命周期很短，同样的基础设施可以处理更多的用户请求，同时响应式的开发方