《第一章:分布式微服务架构设计原理》
Spring 框架有两个核心思想: IOC AOP。
Spring IOC 指的是控制翻转,将传统 EJB 基于容器的开发改造成普通的 Java 组件的开发,井且在运行时由 Spring 容器统一管理和串联,服务于不同的流程,在开发过程中对 Spring 容器没 有强依赖,便于开发、测试、验证和迁移。使用 EJB 实现 个服务化组件 Bean 时,需要依赖于 多个容器接口 ,并需要根据容器的规则进行复杂的 XML 置,测试需要依赖于应用服务器的环 境,有诸多不便;使用 Spring 框架则不然,开发业务逻辑时每个业务逻辑的服务组件都是独立的, 而不依赖于 Spring 框架,借助 Spring 容器对单元测试的支持,通过对下层依赖服务进行 Mock, 每个业务组件都可以在一定范围内进行单元化测试,而不需要启动重型的容器来测试。
对Java
字节码进行重新编译,将切面插入宇节码的某些点和面上,可以使用
cglib
库实现。
|
定制类加载器,在类加载时对字节码进行补充,在字节码中插入切面,增加了除业务逻辑外的功能, JVM
自身提供的
Java
Agent
机制就是在加载类的宇节码时,通过增加切面来实现 AOP
的。
|
JVM
本身提供了动态代理组件,可以通过它实现任意对象的代理模式,在代理的过程中可 以插入切面的逻辑。可以使用 Java
提供的
APIProxy.newProxylnstanceO
InvocationHandler 来实现。
|
注释:
AspectJ
是实现
AOP
的专业框架和平台,通过
AspectJ
可以实现任意方式的字节码切
面,
Spring
框架完全支持
AspectJ
|
ORM框架,它能够将对象转化成关系,也可以将关系 转化成对象,于是,Hibernate框架出现了。Hibernate通过配置对象与关系表之间的映射关系,来 指导框架对对象进行持久化和查询,并且可以让应用层开发者像执行SQL一样执行对象查找。这 大大减少了应用层开发人员写SQL的时间。
SOA代表面向服务的架构,即服务化。SOA将应用程序的模块化组件通过定义明确的接口和契约联系起来,接口是釆用中立的方式进行定义的,独立于某种语言、硬件和 操作系统,通常通过网络通信来完成,但是并不局限于某种网络协议,可以是底层的TCP/IP, 可以是应用层的HTTP,也可以是消息队列协议,甚至可以是约定的某种数据库存储形式。这 使得各种各样的系统中的模块化组件可以以一种统一和通用的方式进行交互。
对比JEE和SSH时代的模块化组件后发现,SOA将模块化组件从单一进程中进一步拆分, 形成独立的对外提供服务的网络化组件,每个网络化组件通过某种网络协议对外提供服务,这 种架构下的特点如下:
- SOA定义了良好的对外接口,通过网络协议对外提供服务,服务之间表现为松耦合性, 松耦合性具有灵活的特点,可以对服务流程进行灵活组装和编排,而不需要对服务本 身做改变。
•组成整个业务流程的每个服务的内部结构和实现在发生改变时,不影响整个流程对外提供 服务,只要对外的接口保持不变,则改变服务内部的实现机制对外部来说可以是透明的。
- SOA在这一时代的数据通信格式通常为XML,因为XML标记定义在大规模、高并发 通信过程中,冗余的标记会给性能带来极大的影响,所以后来被JSON所取代。
- SOA通过定义标准的对外接口,可以让底层通用服务进行下沉,供多个上层的使用方 同时使用,增加了服务的可重用性。
- SOA可以让企业最大化地使用内部和外部的公共服务,避免重复造轮子,例如:通过 SOA从外部获取时间服务。
SOA的两个主流实现方式:Web Service 和 ESB。
每个服务之间是对等的,并且互相是解耦的,通过WSDL定义的服 务发现接口进行访问,并通过SOAP协议进行通信。SOAP协议通常是一种在HTTP或者HTTPS 通道上传输XML数据来实现的协议,但是每个服务都要依赖中心化Web Service目录来发现现 存的服务。
Web Service的工作原理如下。
服务提供者Web Service 2和Web Service 3通过UDDI协议将服务注册到Web Service 目录服务中。
•服务消费者Web Service 1通过UDDI协议从Web Service目录中查询服务,并获得服务 的WSDL服务描述文件。
• 服务消费者Web Service 1通过WSDL语言远程调用和消费Web Service 2和Web Service 3提供的服务。
通过这个过程,要改造一个新的业务流程,可以从Web Service目录中发现现有的服务,并 最大限度地重用现有的服务,经过服务流程的编排来服务新的业务。
Web Service的问题如下。
依赖中心化的服务发现机制。
使用SOAP通信协议,通常使用XML格式来序列化通信数据,XML格式的数据冗余 太大,协议太重。
•服务化管理和治理设施并不完善。
微服务架构倡导将软件应用设计成多个可独立开发、可配置、可运行和可维护的子服务, 子服务之间通过良好的接口定义通信机制,通常使用RESTfUl风格的API形式来通信,因为 RESTfol风格的API通常是在HTTP或者HTTPS通道上传输JSON格式的数据来实现的,HTTP 协议有跨语言、跨异构系统的优点,当然,也可以通过底层的二进制协议、消息队列协议等进 行交互。这些服务不需要中心化的统一管理,每个服务的功能可自治,并且可以由不同的语言、 系统和平台实现。
微服务架构致力于松耦合和高内聚的效果,与SOA和ESB相比,不再强调服务总线和通 信机制的多样性,常常通过RESTful风格的API和轻量级的消息通信协议来完成。