1. API启动模版

1.1 api-starter

当我们在企业级应用中采用微服务架构时，往往需要构建多个Restful API，为了便于技术管理并且让学习曲线趋向平缓，我们希望各个API遵循一定的模式，项目实践中，我们创建了一个api-starter，包含readme模版，统一的目录结构，基本的依赖如spring-boot，静态代码管理工具如checkstyle/findbugs等，日志配置等各个API都需要的基础设施。这样，当某个项目需要创建新的API时，可以基于api-starter快速创建，使得开发人员更多的专注与业务逻辑。

2. API Gateway

参见之前写的API Gateway文章

https://www.jianshu.com/p/1803b8609e0b

3. 契约测试

参见之前写的契约测试文章

https://www.jianshu.com/p/c0e5ee510ece

4. 持续交付 & Devops

参见之前写的关于持续集成持续交付文章：

https://www.jianshu.com/p/67f345ebec9b

     4.1 持续交付流水线

     4.2 基础设施即代码

参见之前写的文章：https://www.jianshu.com/p/2b8b494c75dd

              4.2.1 Ansible

参见之前写的文章：https://www.jianshu.com/p/c624ac1229b8

5. Health Monitor

5.1 spring boot actuator

对于基于spring boot的应用，spring boot actuator提供了/health接口用于监测当前服务是否可用。我们只需要在项目中引入spring-boot-starter-actuator的依赖；默认情况下，actuator提供/health的url路径，且无须认证信息即可访问。

5.2 Hystrix

Hystrix is a latency and fault tolerance library designed to isolate points of access to remote systems, services and 3rd party libraries, stop cascading failure and enable resilience in complex distributed systems where failure is inevitable.

分布式的系统中存在着各个服务之间复杂的依赖关系，那么如果某个服务存在高延迟或不可用的情况，如何保证依赖它的其他服务不受影响？这就是Hystrix尝试解决的问题。总体来说，Hystrix提供了health check和circuit breaker的功能。

Hystrix是如何做到的呢？

（1）把所有外部系统的调用包装在HystrixCommand（命令模式的例子）。

（2）设置阈值，请求时延超过该阈值即为超时。

（3）为每个外部依赖维护一个小的线程池，当线程池被用完后，拒绝新的请求。

（4）记录成功调用的次数，失败次数，超时次数和拒绝请求次数。

（5）通过circuit-breaker，当失败次数超过阈值，则在一段时间内停止发送请求。

（6）当请求失败/超时/被拒绝/被短路时，调用配置的回调函数。

circuit breaker是指：当A服务实时调用B服务时，B有可能发生不可用或者高延迟的情况，此时A的线程资源可能会在等待中被占用，最糟糕的情况会造成资源耗尽导致A也服务不可用，从而引发传递性失败。为了解决这个问题，A服务可以通过代理访问B服务，当连续出现的失败次数超过配置的门限时，即触发断路，接下来timeout时间内对B服务的调用都会不经尝试，直接失败。timeout时间过后，cirtuit breaker会允许通过一部分到B服务的请求，如果成功则继续正常调用，如果失败那么又开始新一轮的timeout处理。

关于Hystrix的更多信息：https://github.com/Netflix/Hystrix/wiki

此外，Hystrix还提供了资源/依赖隔离(线程池隔离)：它会为每一个依赖服务创建一个独立的线程池，这样就算某个依赖服务出现延迟过高的情况，也只是对该依赖服务的调用产生影响， 而不会拖慢其他的依赖服务。

Hystrix提供几个熔断关键参数：滑动窗口大小（20）、 熔断器开关间隔（5s）、错误率（50%）。每当20个请求中，有50%失败时，熔断器就会打开，此时再调用此服务，将会直接返回失败，不再调远程服务。直到5s钟之后，重新检测该触发条件，判断是否把熔断器关闭，或者继续打开。

6. 日志管理

参见文章：https://www.jianshu.com/p/a474e63f4dc6

参见文章：https://www.jianshu.com/p/9f0b168451ab

7. 主流微服务架构图

1）网关集群：数据的聚合、实现对接入客户端的身份认证、防报文重放与防数据篡改、功能调用的业务鉴权、响应数据的脱敏、流量与并发控制等。

2）业务集群：一般情况下移动端访问和浏览器访问的网关需要隔离，防止业务耦合。

3）Local Cache：由于客户端访问业务可能需要调用多个服务聚合，所以本地缓存有效的降低了服务调用的频次，同时也提示了访问速度。本地缓存一般使用自动过期方式，业务场景中允许有一定的数据延时。

4）服务层：原子服务层，实现基础的增删改查功能，如果需要依赖其他服务需要在 Service 层主动调用。

5）Remote Cache：访问 DB 前置一层分布式缓存，减少 DB 交互次数，提升系统的TPS。

6）DAL：数据访问层，如果单表数据量过大则需要通过 DAL 层做数据的分库分表处理。

7）MQ：消息队列用来解耦服务之间的依赖，异步调用可以通过 MQ 的方式来执行。

8）数据库主从：服务化过程中必经的阶段，用来提升系统的 TPS。