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

1.1 从传统的单体架构到服务化架构

1.1.1 J2E架构t

• 特点
  在单体系统上，也进行了分层和逻辑拆分
• 问题
  但是，在每个层次上，多个业务 还是耦合在同一个应用中。

1.1.2 SSH架构

• 特点
  通过spring的ioc和aop，以及MVC，使层次更简单、轻量
• 问题
  每个层次上还是存在业务耦合，即使通过package划分，也不彻底，时间长了也就乱了。

1.1.3 服务化 架构

• 背景
  单体系统无法满足互联网海量用户请求，水平扩展也很有限。
• 特点
  SOA 面向服务的架构，简称服务化架构。
  它将模块组件从单一进程中拆分成对外提供服务的网络化组件；通过定义标准的对外接口，让底层通用服务进行下沉，增加服务可重用性；避免重复造轮子。
• 2个主流实现方式
  webservice
  ESB
• 存在的问题
  webservice：
  依赖中心化的注册发现
  xml格式数据通信冗余大，协议重
  服务化管理和治理设施不完善

ESB：
总线本身也是中心化管理模型，系统变更的影响范围大
试图通过总线隐藏复杂性，但是系统内部的复杂性仍然存在

1.2 从服务化到微服务

1.2.1微服务架构的产生

• 见上边 服务化 架构的缺陷

1.2.2 微服务架构与传统单体架构的对比

• 把每一个职责单一的功能放在一个独立的服务中
• 每个服务都应该有自己的数据存储、缓存服务等，甚至运营等
• 每一个服务都可以根据性能要求进行水平伸缩

1.2.3 微服务架构与SOA服务化的对比

• 首先，二者并不冲突，微服务是服务化的升华落地的一种方式
• 微服务更注重拆分小的粒度，以实现快速迭代、职责清晰、快速组合实现业务流程等

1.3 微服务架构的核心要点和实现原理

1.3.1 职能团队划分

一个服务一个团队维护

1.3.2 微服务的去中心化治理

最差也要在中心化配置集群挂掉时，能降级，如使用客户端缓存路由

1.3.3 微服务的交互模式

• 引言：微服务的交互的通用设计模式
• 1.读者容错
  消费者对返回值进行过滤，只要自己需要的核心数据无问题，则可抛弃多余数据继续处理，而不是硬生生的抛错。
  只有完全不能识别接收到的信息或者无法继续处理流程，再抛错。
• 2.消费者驱动契约模式
  提供者契约：
  消费者契约：
  消费者驱动的契约：消费者把自己的期望告诉提供者，则提供者无论何时，都要遵守契约。
  -3. 抛弃数据共享模式
  数据共享带来的问题：
  除了接口契约，还存在了数据存储契约，一旦有变，下游逻辑就出问题。
  对共享资源难以划定界限。
  跨机房的服务调用不能使用独立的资源部署模式，难以实现服务的自治
• 总结：一定不要共享缓存和数据库资源等

1.3.4 微服务的 分解和组合 模式

• 引言：在微服务的 需求分析和架构设计 过程中，通常是用领域的动词和名词来划分微服务的。
  例如，对于一个电商后台，可以分解为 订单、商品、目录、库存、购物车、交易、发票、、、每一个名词和动词都可以是一个微服务
  说人话就是：把能想到的领域词汇晒一遍，看看哪些可以做成微服务。
  以下是讲 用什么方式组合这些微服务

• 1. 服务代理模式
     典型案例是 做平滑的系统迁移。通常有4个阶段：
     新老系统双写
     迁移双写之前的历史遗留数据
     将读请求切换到新系统（一般会有一个开关）
     下掉双写，只写新系统
• 2. 服务聚合模式
• 3. 服务串联模式

• 4.服务分支

• 5.服务异步消息模式
  通常会梳理 核心系统的最小化服务集合。这些核心的使用同步调用，而核心之外的可以使用异步消息队列进行异步化。

• 6.服务共享数据模式
  虽然上边提到不建议这样，但是有2种场景下需要这样做：1.单元化架构 2.遗留的整体服务

1.3.5 微服务的容错模式

1.舱壁隔离模式

• 1.微服务容器分组
  例如，将社交名人流量路由到服务的核心池，普通用户到另一个池子。
• 2.线程池隔离
  不同功能的线程池要隔离

2.熔断模式

3.限流模式

常见技术实现：

• 1.计数器
• 2.令牌桶
• 3.信号量
• 4.失效转移模式
  在熔断、限流之后，如何处理被拒绝的请求呢？ 一般解决模式就是：失效转移模式。细分为：
  a. 快速失败策略，直接返回错误，让调用方知道发生了问题而进行后续处理
  b. 如果有备份服务，就切到备份。
  c. 如果失败的服务只是单台机器偶尔有问题，如fullgc，oom等，此时适合使用 failover 策略，采用重试的方法来解决。（注意幂等）

1.3.6 微服务的粒度

• 1.不能太细
  会导致服务数量多，依赖关系复杂，维护团队多成本大，不切实际。
• 2.怎么样合适
  适可而止：可以让使用方自由地编排底层的子服务来获得相应的组合服务即可。当然也要适合自己团队的建设和布局。

1.5 服务化管理和治理框架的技术选型

1. 服务化

• dubbo
• thrift
• HSF

2.微服务

• spring boot
  是spring cloud 构建微服务架构的重要基础
• Netflix
  各种熔断、监控、报警、、、
• spring cloud Netflix