巨无霸应用系统带来的问题

1.编译、部署困难

2.代码分支管理困难

3.数据库连接耗尽

4.新增业务困难

解决方案就是：拆分，将模块独立部署，降低系统的耦合性

1.纵向拆分：讲一个大应用拆分成为多个小应用，如果新增业务较为独立，name就直接将其设计部署为一个独立的web应用系统

2.横向拆分：将服用的业务拆分出来，独立部署为微服务，新增业务只需要调用这些微服务即可。



Web Service的缺点

1.臃肿的注册与发现机制

2.抵消的XML序列化手段

3.开销相对较高的HTTP远程通信

4.复杂的部署与维护手段

这些原因导致难以满足大型网站对系统高性能、高可用、已部署、易维护的要求。



微服务框架需求

除了web service规范的服务注册与发现，服务调用等标准功能，还需要微服务框架能够支持：

1.失效转移（Fail Over）:支持服务提供者的失效转移机制，以实现服务高可用

2.负载均衡：服务提供者可以使用加权轮询等手段访问，是服务提供者集群实现负载均衡

3.高效的远程通讯

4.对应用最少侵入：服务模块本身需要支持集中式部署，也可分布式部署

5.版本管理：快速变化的需求，服务版本升级不可避免，保持服务提供者与请求者，支持低版本接口，直到请求者接口升级后，才能关闭历史版本服务。



Service Mesh 服务网络

Service Mesh是一个基础设施层，用于处理服务间的通信，通常表现为一组轻量级网络代理，他们与应用程序部署在一起，对应用程序透明



微服务架构落地

1.业务先行，先理顺业务边界和依赖，技术是手段而不是目的

2.现有独立的木块，后又分布式的服务

3.业务耦合验证，逻辑复杂多变的系统进行微服务重头要晋升

4.高清出实施微服务的目的：业务服用、开发边界清晰、分布式集群提升性能。



命令与查询职责隔离（CQRS）

在服务接口层面将查询（读操作）与命令（写操作）隔离，实现服务层的读写分离

1.更清晰的领域模型

2.针对读写分别优化，实现更好的性能

3.查询服务不会修改数据，更好的保护读数据



事件溯源

将用户请求处理过程中的每次状态变化都记录到时间日志中，并按时间序列进行持久化存储。

1.利用时间溯源，可以紧缺浮现任何用户状态，进行复核审计

2.利用时间溯源，可以有效监控用户状态变化，并在此基础上实现分布式事务。



断路器

当某个服务出现故障，响应延迟或失败率增加，继续调用这个服务会导致调用者请求阻塞，资源消耗增加，进而出现服务级联失效，这种情况下使用断路器阻断对故障服务的调用，断路器三种状态：关闭，打开，半开