5.携程架构实践 — 框架中间件

第5 章 框架中间件 

中间件可以简化应用的通信方式，使不同的进程不再需要调用复杂的系统函数也可以完成，甚至以更多的方式进行数据传输；中间件也可以为上层应用提供
更友好的接口，以便应用更方便的操作系统设备。所以，从这个意义来说，"胶水"的概念，一方面是指中间件能够"粘合"不同的应用，另外一方面是指中间件
能够"黏合"应用和操作系统。
	
	互联 领域的中间件，主要是指在分布式系统中被广泛使用的中间件软件，一般用于提供通信和数据管理服务。中间件的优势，主要在于提供了对调用方提供了更好的
封装性：
	1.封装了底层操作的复杂性
		中间件可以根据公司基础设施及用户需求等实际情况，提供经验配置，并使用边界条件的降级策略对调用方进行透明封装，这样，用户就不再需要面对这些复杂性
	了。

	2.封装了公共业务模型的具体实现
		对于调用方来说，很多中间件api和jdk中对应用数据结构的api并无明显区别，它们属于同一种业务模型，学习成本很低。但这种封装性扩大了既有模型的作用
	范围(从线程到进程)，提升了调用方的业务逻辑表达能力，降低了用户系统架构改造的成本和负担。

	3.良好的封装性带来了更好的模块性	
		中间件在某种程度上可以被认为是对公共业务逻辑的封装，直接使用定义清晰的中间件接口，一方面可以简化了业务逻辑架构，有利于业务逻辑缺陷更容易的暴露
	出来；另一方面将公共业务逻辑的缺陷封装在中间件中，有利于对这些缺陷进行修复，不再需要全局参与。

 
	中间件介绍：
		1.服务化
		2.消息队列
		3.配置中心
		4.数据访问
		5.缓存层

5．1 服务化 
		搭建一个服务化的架构体系可以为系统带来独立的扩展性，隔离故障和资源访问，提升系统的可维护性。

	5．1．1 为什么需要服务化中间件框架 
		服务化的架构体系提倡将原本单一的应用程序划分为一组应用程序。每一个应用针对特定的业务场景和需求进行构建，并且能够进行独立的开发，测试，部署和
	升级。同时，为了应对不同的场景和业务流程，这些应用还可能使用不同的技术栈进行搭建。在拆分后，原本应用内的方法调用就需要转变成应用间的远程过程调用。

		提到应用间的远程调用，就不可避免的涉及以下几个问题：
			1.如何将代码中的业务数据转化为远程过程调用时用于传输的数据(即序列化)，并且可以在另一端再转化回来(反序列化)。
			2.应用如何获得自己的依赖的服务的调用地址和传输的数据格式。
			3.如何确保应用依赖的服务是高可用的。
			4.服务端应用如何管理自身的工作状态。
			5.如何降低应用用于发起调用的代码量和复杂度。
			6.远程过程调用如何进行认证，授权，流量控制和服务降级。

		为了解决这些问题，我们都需要做什么/span>
			1.一个对象序列化解决方案。它不仅需要具备准确性和高性能，还需要兼顾平台通信所带来的复杂性。
			2.一个服务注册中心。它可以提供服务的注册和发现功能。
			3.一个服务健康监测机制。它可以使外部实时感知服务的工作状态。
			4.一个高度封装的客户端实现。应用通过其暴露的简单接口就可以发起远程过程调用。
			5.一个服务治理系统。用户可以在系统中管理服务的各项配置。

	5．1．2 服务化中间件框架的基本架构 
		从客户端到服务端再到外围的支持系统，我们可以整理出服务化中间件框架的基本组成部分：服务端框架，客户端框架，服务注册中心和服务治理系统。
			1.服务端框架
				服务端框架工作在服务端应用内，将代码里的一个接口暴露为一个服务并允许其他应用调用。它支持使用不同的数据传输格式(如xml,json,pb)进行
			调用以使用不同的业务场景。它还会与注册中心进行通信，告知其自身的调用地址。同时，它集成了一系列外围服务治理类功能，如健康监测，认证授权，
			限流，熔断，服务降级等。

			2.客户端框架
				客户端框架工作在客户端应用内，将其他应用的一个服务接口映射到应用内，形成一个本地调用。其中封装了支持不同数据传输格式的序列化器，与
			注册中心交互的服务发现机制，在不同服务实例间分配流量的负载均衡器等。此外，它也需要包括客户端错误处理的熔断和服务降级机制。

			3.服务注册中心
				服务注册中心可以说是功能最单一的一个组件。它对外提供服务注册与发现功能，虽然功能简单。服务注册中心需要保证在极大的请求量下仍旧能够
			稳定工作，保证数据的准确性和一致性，并且可以在实时的将服务注册信息的变更推送给客户端框架。

			4.服务治理系统
				服务治理系统可以说是所有组件中最独立的，而且是所有组件中唯一提供用户使用界面的。它为用户提供了服务信息管理，服务实例管理，服务配置
			管理等治理功能。但其内部也会时刻与工作在应用内的框架组件进行交互，推送服务配置信息。

	5．1．3 服务注册中心设计解析 
		第三代服务注册中心，参考了Netflix的Eureka。一个注册中心集群由多个节点组成。各个节点的地位相同，无主次之分。由于服务实例注册信息的动态性，
	这些信息并不会被持久化到后端存储中，而是会被保存到各个节点的内存中。服务的注册和心跳请求会被接收请求的节点分发到其他节点，从而保证集群数据的一致
	性。同时基于内存的读写可以为整个系统提供一个很好的响应性。后端数据库主要用于保存一些服务实例的配置数据。

	5．1．4 服务治理系统功能解析 
		服务治理系统是连接用户与服务化中间件框架的桥梁。用户可以在服务治理系统中 创建服务，管理服务的元数据和相关配置。服务治理系统负责将数据推送给
	相应的框架组件，并在用户中生效。

		xc 的服务治理系统分为两部分：一部分是面向用户的web应用(用户界面)，另外一部分是面向框架组件的核心数据接口服务(核心数据API)。
			1.用户界面包括 服务元数据管理，服务运维，服务配置管理，服务运行监控。

				归属部门，负责人，访问方式和当前状态等
				
				b) 服务运维，则包括服务在运行时的各项管理功能，如 服务实例管理，服务路由管理等。
					1.服务实例管理可以说是用户最常用的功能。我们将服务实例的状态拆分为4个部分：服务器状态，实例状态，发布状态和健康状态，
					分别对应服务器的维护，服务实例的人为拉入，拉出操作，应用发布操作，健康监测的拉入，拉出操作。
					2.服务路由管理是服务请求分配的一个高级功能。在默认情况下，客户端的请求会在所有服务实例之间进行轮询分配。在某些场景下，如数据
					中心故障，蓝绿发布，应用迁移等，服务负责人需要定制请求分配的规则。这就是自定义服务路由需要实现的功能。服务路由管理支持3种路由
					类型：全局路由，操作路由和请求路由。
						全局路由，是对所有的服务请求的分配方式；
						操作路由，是对某个或某几个特定的服务请求的分配方式；
						请求路由，是允许业务代码在发起请求时告知客户端框架档次请求所使用的分配方式。

					每条路由可以绑定一个或者多个服务实例分组并为其分配权重。所有的路由规则都会被推送至客户端。在发起请求时，客户端会根据选定的路由
				规则和实例分组权重确定最终接收请求的服务实例，并向其发起调用。

				c)服务配置管理，可以是控制框架组件中各个功能的开关与参数，包括前文提到的限流，熔断，降级，认证授权等。限流支持服务和操作两个级别，
				全局，客户端应用和Ip三个维度。熔断的配置的主要内容是相应的阈值参数。认证授权支持配置应用标识和客户端ip地址两种白名单。

				d)服务运行监控，包括请求量，请求和响应数据大小，请求响应时间及请求并发量等。

			2.核心数据API
				负责与内部的客户端和服务端框架，注册中心及外部各个依赖系统对接。API与哦用户界面共享一套数据模型和后端存储，并通过restful API对外
			提供数据访问接口。API主要有以下类型：服务元数据API，服务实例管理API，服务路由管理API，服务配置管理API等。

 
5．2 消息队列 
	5．2．1 消息队列的特性与使用场景 
		消息队列的特性：
			1.异步
			2.松耦合
			3.数据分发
			4.流量削峰
			5.可靠投递

		下列场景推荐使用消息队列：	
			1.上下游业务解耦
			2.延迟通知
			3.大数据离线分析
			4.缓存同步

	5．2．2 主流消息队列 
		kafka 拥有成熟的生态，活跃的 区和巨大的实例集群。kafka将一个topic分成多个Partition(分片/分区)，每一个Partition是一个Broker上的
	物理文件，通过Append Only 的方式实现文件顺序写的高性能，可以线性提高集群中单topic的吞吐量。kafka写入消息时，会有一个潜在的风险：当Broker
	上所有的topic的Partition总和过多时，可能会产生随机写。

	5．2．3 携程消息队列QMQ 
		1.生产消息的可靠投递与事务消息
		2.延迟消息
		3.定时重试
		4.同机房生产与消费
		5.消息检索与追踪

5．3 配置中心 
	5．3．1 为什么需要配置中心 
		配置是一种有形的安排。它依托于某种形式，同时具有控制力。



                                                        
声明：本站部分文章及图片源自用户投稿，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！