1、分布式微服务架构设计原理

 

一、单体服务架构

1、JEE架构:UI、EJB逻辑层、数据库

1、分布式微服务架构设计原理_第1张图片

优点:对单体架构分层,接入层、逻辑层、数据层;

缺点:

a、逻辑层业务耦合性高,组件指责划分不清晰,导致新功能迭代,增加和维护非常困难。

b、EJB2.0实现采用了大量的XML配置文件,组件学习曲线高、难以单元测试,超重量级;

 

2、SSH架构:Structs(UI 交互层)、Spring(业务逻辑实现)、Hibernate(对象领域的模型与关系型数据库模式映射)

Structs MVC模型:

1、分布式微服务架构设计原理_第2张图片

  Spring:逻辑层实现核心容器,核心思想 IOC和AOP

a、IOC(控制反转):

       EJB 实现: 实现服务化组件 Bean 时,强依赖多个容器接口,复杂容器规则的 XML配置,测试依赖应用服务器环境;

      Spring 实现:业务逻辑服务组件都是独立的,Spring 容器支持单元测试,对下层依赖服务进行 Mock, 方便测试。

 
b、AOP(面向切面编程):日志、安全、事物、应用程序性能APM; 具体实现:AspectJ
 
 
Hibernate:对象领域模型与关系型数据库模型映射
 
存在性能问题,使用更加灵活的MyBatis实现ORM
 
1、分布式微服务架构设计原理_第3张图片
 

   二、服务化架构 SOA

    1、WebService:

1、分布式微服务架构设计原理_第4张图片

    原理:

       1)通过UDDI协议注册WebService服务目录

       2)通过UDDI协议查询服务,并获得WSDL服务描述文件

       3) 通过WSDL语言远程调用WebService提供服务

    缺点:

        1)依赖中心服务发现机制

         2)使用SOAP通信协议,通过XML序列和反序列化数据

         3)服务化管理和治理设施不完善

 

    2、ESB: 企业服务总线

1、分布式微服务架构设计原理_第5张图片

原理:

1、每个服务提供者通过总线模式插入系统

2、总线根据路程的编排将服务的输出转化为流程的下一个输出节点

缺点:

1、ESB服务过重的整体服务

2、通过ESB试图隐藏系统内部的复杂性,但是系统内部复杂性依旧存在

 

三、微服务架构

1、职能团队划分

1、分布式微服务架构设计原理_第6张图片

2、去中心化服务治理

微服务架构倡导去中心化的服务管理和治理,尽量不要设置中心化的管理服务,最差在中心化管理服务瘫痪时有替代方案和设计。

API网关:所有外部服务和内部服务通过API网关统一管理

缺点:用户请求通过机房,都需要经过API网关路由,服务上量后,很大程度上放量了API网关的调用TPS。

 

3、微服务交互模式

a、读者容错模式:服务提供与消费者之间对接口改变进行容错

b、消费者驱动契约模式:

1、分布式微服务架构设计原理_第7张图片

举例:

生产者契约:账务系统入账请求(商户账户ID、入账订单号、入账金额)

消费者契约:账务系统入账返回(商户账户ID、入账订单号、入账金额、入账时间、财务流水号、入账状态)

 消费者驱动契约:对于交易系统只需要账户系统的入账订单号和入账状态,为了保证资金的安全,交易系统对账务系统发起者

提出幂等和滤重处理,对重复的入账请求进行拦截。

c、去数据共享模式

1、分布式微服务架构设计原理_第8张图片

缺点:

a、微服务之前交互除了接口契约,还有数据存储契约

b、上有数据格式发生变化时,可能导致下游处理逻辑出现问题

在数据服务时,一定不要共享缓存和数据库等资源。

 

4、微服务的分解和组合模式

分解:

微服务架构需求分析和架构设计中,通常用领域的动词和名词来划分。拆分后,系统具有敏捷性、灵活性、可伸缩性。

例如电商后台系统,可分解为订单、商户、商户目录、库存、购物车、交易、支付、发票、物流等子系统

 

组合:

1、服务代理模式:

1、分布式微服务架构设计原理_第9张图片

平滑系统迁移四阶段:

1)、新老系统双写

2)、迁移双写之前的历史遗留数据

3)、读请求切换新系统

1、分布式微服务架构设计原理_第10张图片

4)、下调双写逻辑、,只写新系统

 

2、服务聚合模式

根据业务流程处理的需要,按一定的顺序调用一依赖的多个服务,对依赖的微服务返回的数据进行组合、加工和转换,最后按一定的形式返回给使用方。

1、分布式微服务架构设计原理_第11张图片

3、服务串联模式,类似工作流

1、分布式微服务架构设计原理_第12张图片

四、技术选型

1、RPC

1)JDK RMI:JDK1.4后内置远程服务调用技术栈,不采用

a、RMI采用自带JDK专用序列化协议,不能跨语言

b、使用底层网络协议,不如基于文本的HTTP可读

2)Hessian和Burlap

a、基于Http传输。

b、Hessian将对象序列化成语言无关的二进制协议

      Burlap将对象序列化成与语言无关的XML数据

c、都适合传输较小对象,大复杂对象,都没有RMI有优势

 

2、服务化时代框架 (过时)

Dubbo:提供高性能和透明化的RPC远程服务调用,包含基本服务监控、服务治理和服务调度能力

      默认采用传输Hessian序列化数据,Dubbo采用ZooKeeper作为注册中心来注册和发现服务。

      并通过客户端负载均衡来路由请求,算法包括:随机、轮询、最少活跃调用数、一致性hash等。

HSF:淘宝内部大规模使用,不开源。

Thrift: 高性能支持多语言服务调用框架,Apache开源,具有跨语言和高性能优点。

AXIS: Apache Web Service项目,采用SOAP协议

Mule ESB:

3、微服务框架

1)Spring Boot

a、JEE时代

Tomcat Web容器服务管理服务的启动、停止、监控、配置和日志,应用人员按照规范打包War

1、分布式微服务架构设计原理_第13张图片

b、Spring Boot,将容器嵌入自动的Jar包中。Spring Boot启动时,内部启动嵌入的容器,例如Tomcat,Jetty,Nettry等。
1、分布式微服务架构设计原理_第14张图片

2、Spring Clound Netfix 

包含组件Eureka、容错性组件Hystrix、智能路由组件Zuul和客户端负载均衡组件Ribbon

1、分布式微服务架构设计原理_第15张图片

Netflix交互流程

1、服务在Eureka服务器实例上注册

2、Zuul作为特殊服务在Eureka注册并发现服务

3、Zuul作为网关,将发现服务给PC网站、APP和开放平台使用

4、RestTemplate和FergnClient使用简单服务调用方法调用服务1、服务2

 

 

你可能感兴趣的:(2,大型网站架构)