1、分布式微服务架构设计原理
⼀、单体服务架构
1、JEE架构：UI、EJB逻辑层、数据库
优点：对单体架构分层，接⼊层、逻辑层、数据层；
缺点：
a、逻辑层业务耦合性⾼，组件指责划分不清晰，导致新功能迭代，增加和维护⾮常困难。
b、EJB2.0实现采⽤了⼤量的XML配置⽂件，组件学习曲线⾼、难以单元测试，超重量级；
2、SSH架构：Structs（UI 交互层）、Spring（业务逻辑实现）、Hibernate（对象领域的模型与关系型数据库模式映射）Structs MVC模型：
Spring：逻辑层实现核⼼容器，核⼼思想 IOC和AOP
a、IOC（控制反转）：
E JB 实现： 实现服务化组件 Bean 时，强依赖多个容器接⼝，复杂容器规则的 XML配置，测试依赖应⽤服务器环境；
Spring 实现：业务逻辑服务组件都是独⽴的，Spring 容器⽀持单元测试，对下层依赖服务进⾏ Mock, ⽅便测试。
b、AOP(⾯向切⾯编程）：⽇志、安全、事物、应⽤程序性能APM； 具体实现：AspectJ Hibernate：对象领域模型与关系型数据库模型映射
存在性能问题，使⽤更加灵活的MyBatis实现ORM
⼆、服务化架构 SOA
1、WebService:
原理：
1）通过UDDI协议注册WebService服务⽬录
2）通过UDDI协议查询服务，并获得WSDL服务描述⽂件
3） 通过WSDL语⾔远程调⽤WebService提供服务
缺点：
1）依赖中⼼服务发现机制
2）使⽤SOAP通信协议，通过XML序列和反序列化数据
3）服务化管理和治理设施不完善
2、ESB: 企业服务总线
原理：
1、每个服务提供者通过总线模式插⼊系统
2、总线根据路程的编排将服务的输出转化为流程的下⼀个输出节点
缺点：
1、ESB服务过重的整体服务
2、通过ESB试图隐藏系统内部的复杂性，但是系统内部复杂性依旧存在
三、微服务架构
1、职能团队划分
2、去中⼼化服务治理
微服务架构倡导去中⼼化的服务管理和治理，尽量不要设置中⼼化的管理服务，最差在中⼼化管理服务瘫痪时有替代⽅案和设计。API⽹关：所有外部服务和内部服务通过API⽹关统⼀管理
缺点：⽤户请求通过机房，都需要经过API⽹关路由，服务上量后，很⼤程度上放量了API⽹关的调⽤TPS。
3、微服务交互模式
a、读者容错模式：服务提供与消费者之间对接⼝改变进⾏容错
b、消费者驱动契约模式：
举例：
⽣产者契约：账务系统⼊账请求（商户账户ID、⼊账订单号、⼊账⾦额）
消费者契约：账务系统⼊账返回（商户账户ID、⼊账订单号、⼊账⾦额、⼊账时间、财务流⽔号、⼊账状态）
消费者驱动契约：对于交易系统只需要账户系统的⼊账订单号和⼊账状态，为了保证资⾦的安全，交易系统对账务系统发起者
提出幂等和滤重处理，对重复的⼊账请求进⾏拦截。
c、去数据共享模式
缺点：
a、微服务之前交互除了接⼝契约，还有数据存储契约
b、上有数据格式发⽣变化时，可能导致下游处理逻辑出现问题
在数据服务时，⼀定不要共享缓存和数据库等资源。
4、微服务的分解和组合模式
分解：
微服务架构需求分析和架构设计中，通常⽤领域的动词和名词来划分。拆分后，系统具有敏捷性、灵活性、可伸缩性。
例如电商后台系统，可分解为订单、商户、商户⽬录、库存、购物车、交易、⽀付、发票、物流等⼦系统
组合：
调用webservice服务1、服务代理模式：
平滑系统迁移四阶段：
1)、新⽼系统双写
2)、迁移双写之前的历史遗留数据
3)、读请求切换新系统
4)、下调双写逻辑、，只写新系统
2、服务聚合模式
根据业务流程处理的需要，按⼀定的顺序调⽤⼀依赖的多个服务，对依赖的微服务返回的数据进⾏组合、加⼯和转换，最后按⼀定的形式返回给使⽤⽅。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。