服务集成服务之间必须要集成，而这种集成关系远比简单的API调用较复杂。对于微服务架构而言，我们的思路是尽量采用标准化的数据结构和通信机制，并降低系统集成的耦合度。我们把微服务架构中的服务之间的集成模式分为以下四类。同时还会引入其他一些手段来实现服务与服务之间的有效集成。接口集成。接口集尝是服务之间集成的最常用的手段，通常基于业务逻辑的需要进行集成。RPC、消息传递和服务总线都可以归为这种集成方式。RPC架构是服务之间进行集成的最基本的方式。在RPC架构的实现思路上，远程服务提供者以某种形式提供服务，调用相关信息，远程代理对象通过动态代理拦截机制生成远程服务的本地代理，让远程调用在使用上如同本地调用一样。而网络通信应该与具体协议无关，通过序列化和反序列化方式对网络数据进行有效的传输。rap represential state transfer，表述性状态转移从技术上讲也可以认为是RPC架构的一种具体表现形式。因为RPC架构中最基本的网络通信、序列化和反序列化、传输协议和服务调用等组件都能在rest中有所体现。但rest代表的并不是一种技术，也不是一种标准和规范。而是一种设计风格。要理解restful架构，最好的方法就是理解它的全称representational这个词组。职业就是表述性状态转移，针对的是网络上的各种资源，resource。所以通俗的讲，rest。就思源在网络中以某种表现形式进行状态转移，消息统计ssae机制或者称为消息传递机制。可认为是一种系统集中组件，是在分布式系统中完成消息的发送和接收的基础软件，用于消除服务交互过程中的耦合度。关于耦合度的具体表现形式，我们在下一节中还会具体展开。消通信机制，实现系统解余的做法是在服务与服务之间添加一个中间层，这样紧耦合的单阶段过程调用就转变成了松耦合的。这样过程可以通过中间层进行消息的存储和处理。这个中间层就是以各种消息中间键为代表的消息通信系统ssain syste企业服务总线enterprise serious boss e sb本质上也是一种系统集成组件，用于解决分布式环境下的异步协作问题，可以看作是对消息通信系统的扩展和延伸。ESB提供的一批核心组件包括路由器、转换器和端点路由器，在一个位置上维护消息目标地址，并基于消息本身或上下文进行路由。转换器transforr用于易购系统之间进行数据适配，数据结构类型、表现形式、传输方式都是潜在的需要转换的对象端点endpoint封装。线系统的交互数据集成数据集成同样可以用于微服务之间的交互。常见的共享数据库share data是一个选择，但也可以通过数据复制data replication的方式实现数据集成。在微服务架构中，我们追求数据的独立性，但对于一些遗留系统而言，无法重新打造数据体系，数据复制就成为了一种折中的集成方法。所谓数据复制，就是在不同的数据容器中保存同一份业务数据。这里的同一份业务数据的概念不在于数据内容的完全一致性，而在于这些数据背后的业务逻辑的一致性。客户端集成。由于微服务是一个能够独立运行的整体，有些微服务会包含一些u界面。时间也可以通过UI界面进行集成。从某一个微服务的角度讲，调用他的服务就是该服务的客户端。由于客户端与微服务之间的集成可以分为三种方式，即直接集成使用front end服务器和使用API网关。直接继承的方式比较简单，就是客户端通过微服务提供的访问入口直接对微服务进行集成，这种方式适用于微服务数量不是太多的场景。如果采用直接继承的方式，服务按照业务模块进行划界。编的和命名是一项最佳实践。friend服务器有时候也可以认为是一种total门户机制，即把客户端所需要的各种CSS javascript report的公共资源统一放在front服务器，然后每个每个微服务包含自身特有的hitil等客户端代码片段以及业务逻辑，通过集成front服务器上的公共资源完成独立服务的运行。当服务数量较多且客户端集成场景比较复杂时，通常就需要单独抽取一层作为客户端访问的统一入口，这一层在微服务架构中称为API网关ateway。网关的主要作用就是对后端的各个微服务进行整合，从而为不同的客户端提供定制化的内容外部集成。这里把外部集成单独剥离出来的原因在于，现实中很多服务之间的集成需求来自于与外部服务的依赖和整合，而在集成方式上，也综合采用接口集成、数据集成和客户端集成。以集成方式各有其应用场景和特点，现实中的很多系统包含的集成方式并不限于其中一种。关于服务拆分和服务集成的方法论和工程实践不是本书的重点，读者可以参考笔者的微服务设计原理和架构一书做进一步的了解。中文重点介绍的就是接口集成，并试图通过响应式编程的方式实现基于restful风格以及消息通信的微服务集成需求。微架构的核心组件微服务的实现首先需要