分布式服务架构(一)
JEE是Java平台企业化的简称，如上就是JEE时代的典型架构，分为web层，业务逻辑层，以及数据存储层,不同层级有自己的职责，每个层级职责单一
虽然JEE对单体应用进行了分层，但是久而久之，随着业务的复杂逻辑迭代增加，以及开发人员的流动，新手可能没有遵循规范，最终还是会导致数据存取之间的耦合性增加，最后导致组件与组件之间难以划分,且大多数还是在一个应用服务器上跑在一个JVM进程中，
MVC框架将用户交互划分为视图，模型和控制器三大块，如上图，
在JEE开始流行还没有完全奠定地为时候，开发软件struts，spring,Hibernate开始流行，很快成为了企业开发的标配(SSH).而SHH时代的架构如下
很明显SSH框架和传统JEE架构类似，可分为三层，实现交互UI接口的Web Mvc层，实现业务员逻辑层Spring层，以及对象关系映射层Hibernate层，每层都比JEE对应的层次简单，更加轻量，不需要开始整个应用服务器即可验证和测试，极大提高了效率这都是spring 的功劳
但是这中架构还是取向于传统的单体应用，业务逻辑耦合在一个项目中。
服务化架构
随着互联网快速突起环境下，传统的架构不能满足海量用户发起的高并发请求，无法突破耦合在一起的模块组件的性能瓶颈,且水平扩展也是很有限。
为了解决上面问题，引入了SOA,俗称服务化，
SOA,将应用之间模块化组件通过定义明确的接口和契约联系起来，接口是采用中立的方式定义，独立于语言开发，硬件，操作系统，通常通过网络通信完成，但不局限与某种网络协议，可以是底层TCP/IP.也可以是应用层的HTTP,也可以是消息队列协议。
而SOA的主流实现有两种,WEB Service和ESB
WEB Service
每个服务对等，并且相互解耦，通过WSDL协议定义的服务发现接口进行访问，并通过SOAP协议进行通信，SOAP协议通常是一种在HTTP或者HTTPS通道上传输XML数据实现协议，但是每个服务都要依赖中心化WEB Service目录发现存在的服务,通过web service目录发现现有服务，并最大限度的重用现有服务。
ESB
ESB是企业服务总线的简称，用于设计和实现网路化服务交互和通信的软件模型，是SOA的另外一种实现。
ESB服务没有中心化服务的服务节点，每个服务提供者都可以通过总线的模型插入系统，总线根据流程的编排负责将服务的输出进行转换并发送给流程要求的下一个服务进行处理。
企业总线是ESB的核心要素,所有服务都可以在总线上插拔，并通过总线的流程编排和协议转接能力来组合实现业务处理能力。
微服务
前面说的SOA服务系统能够分解任务，让每个服务更简单，职责单一，更易扩展，但是不论是Web service服务还是ESB总线，都有一些问题
Web Service
- 依赖中心化的服务发现机制
- 使用SOAP通信协议，通常使用XML格式来序列化通信数据，XML格式数据冗余太大，协议太重
- 服务化管理和治理设施并不完善
ESB
- ESB虽然是SOA实现的一种，却更多的体现了系统集成的便利性，通过统一的服务总线服务组合在一起，并提供组合的业务流程服务
- 组合在ESB上的服务本身可能是一个过重的整体服务，或者是传统的Jee服务，
- ESB通过总线隐藏系统内部的复杂性，但是系统内部的复杂性依然存在
- 总线本身的中心化的管理模式，系统变更影响范围经常随之扩大
而微服务倡导就是应用可以独立开发，可配置，可运行和维护的子服务，子服务之间通过良好的接口定义通信机制，通常是RestFul风格的api形式来通信，可以使用HTTP或HTTPS通信上传输json格式的数据来实现，HTTP具有跨语言，跨异构系统的优点，当然也可以底层的二进制和消息队列协议等进行交互，每个服务功能自治，且可以使用不同的语言
微服务和传统单体架构的对比
微服务职责单一，独立的服务，每个服务单独运行一个进程，且有自己的数据库，每个服务自治，每个服务可根据需求独立的进行对外水平伸缩。
传统架构运行在单一的jvm进程，整个业务Jvm水平扩展，不能业务组件进行扩展，模块间的依赖将不会氢气，互相耦合，互相依赖是常态
微服务和SOA服务化对比
微服务和SOA是一脉相承,微服务是SOA的延续，SOA理念在微服务架构中任然有效，微服务是在SOA服务化的基础上进行了严谨和叠加。
但是他们却略不一样
- 目的不同
SOA服务化涉及的范围更广，强调不同的异构服务之间的协作和契约，并强调有效的继承和业务流程编排，而微服务是拆分服务，是服务敏捷开发和部署，减少团队的沟通，更容易扩展
- 部署方式不同 微服务是每个业务组件可以互相对立部署，而SOA是将业务组件打包一个war包，然后统一在一个应用服务器上
- 服务粒度不同 微服务拆分成更细粒度的服务，服务之间组合的形式进行处理业务流程，而SOA对粒度没有要求，实践中服务往往是粗粒度的，强调接口契约的规范化，内部可能是更粗粒度的划分
微服务的分解和组合模式
服务代理模式
聚合模式
串行模式
服务分支模式
服务异步消息模式
服务共享模式
微服务容错模式
由于服务之间不再是进程内的调用，而是通过网络进行远程调用，当网络通信不稳定或不可靠，一个服务依赖的服务可能出错，超时或者宕机，如果没有及时发现或隔离问题,没有考虑如何应对这种问题，那个最终可能导致服务雪崩，所以采用哪些措施方案来解决
肠壁隔离模式
正如一艘船遇到意外，而其中一个船舱进了水，我们就希望不会影响其他船舱即船舱之间想不隔离，其他船舱不受影响.
- 微服务容器分组
将微服务分切灰度分组和准生产环境，生产环境，灰度环境跑一些普通商户的流量,生产环境跑一些vip用户，准生产环境用于测试使用，如果进行大的重构，我们可以充分利用灰度环境进行验证问题。
- 线程池隔离
往往我在服务中将多个功能在一个服务实例中，这个微服务的不同功能使用同一个线程池，导致一个功能流量增加耗尽线程池的线程，而阻塞其他功能服务
熔断模式
相当于家中的保险丝，当电流过大，自动关闭跳闸，起到保护整个电路系统，
限流模式
计数器
计数器，我们的目的就是在一分钟以内，最高的请求为100个，但是如上图，如果有恶意用户在0:59秒的时候发送了100个请求，在1:00分钟时候也发送了100个请求，此时在一秒钟就要了200个请求，就可能压垮我们的服务
因此我采用滑动窗口的算法，降低这种情况
我们将一分钟分为6个格,每过10秒向前移动一格,每个格都有自己的计数器，当6个格子加载一起超过了限制，就会触发限流，
比如，当0:59到达100请求到了灰色的格子,而1:00的时候又来了100个请求，那么我们的窗口(即6个格子)向右移动一格，滑动窗口的数量为200,大于100个，所以触发了限流
令牌桶
他是通过一个线程在单位时间内生产固定数量的令牌，然后把令牌放入到队列，每次请求需要从桶里拿取一个令牌,拿到令牌后才有资格执行请求调用，否则直接放弃，或者等到拿到令牌在执行，
由于令牌桶有固定大小，当请求速度小于令牌生成速度，令牌桶就会被填满，所以令牌桶能够处理突发流量，也即使短时间内新增的流量系统能够正常处理
漏桶限流算法
主要是控制数据注入网络的速度,平滑网络上的突发流量
漏桶无法处理短时间内的突发流量，漏桶限流算法是一种恒定速度的限流算法
失效转移模式
若服务架构发生了熔断和限流，则应该处理拒绝的请求呢，解决这个问题叫做失效转移模式
- 采用快速失败策略，直接返回服务错误，让使用方知道发生问题并自行解决问题
- 使用备份，如果有备份服务，则迅速切换到备份服务
- 失败的服务可能只是某一台，不是所有，例如发生OOM,这种情况下适合使用failover策略，采用重试的方法来解决，但是这种方法要求服务提供者的服务实现了幂等性