微服务：服务本身的设计、维护以及治理

Web Service 与企业级分布式服务

• 服务提供者通过WSDL（Web服务描述语言，Web Service Dwscription Language）向注册中心（Service Broker）描述自身提供的服务接口属性，注册中心使用UDDI（Universal Description,Discovery,and Integration,统一描述、发现和集成)发布服务提供者提供的服务，服务请求者从注册中心检索到服务信息后，通过SOAP（Simple Object Access Protocol,简单对象访问协议）和服务提供者通信，使用相关服务。

• Web Service 虽然有着成熟的技术规范和产品实现，以及在企业应用领域有许多成功的案例，但是也具有一些固有的缺点：

• 臃肿的注册与发现机制

• 低效的XML序列化手段。

• 开销相对较高的HTTP远程通信。

• 复杂的部署与维护手段。

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

微服务框架需求

• 对于大型互联网，除了Web Service 所规范的服务注册与发现，服务调用等标准功能，还需要微服务框架能够支持：

• 负载均衡

• 对于集群部署的服务提供者，服务请求者可以使用加权轮询等手段访问，使服务提供者集群实现负载均衡。

• 失效转移(Fail Over)

• 对于大型网站的微服务而言，即使是很少访问的简单服务，也需要集群部署，同时微服务框架还需要支持服务提供者的失效转移机制，以实现服务高可用。

• 高效的远程通信

• 对于大型网站，核心服务每天的调用次数会达到数以亿计，如果没有高效的远程通信手段，服务调用可能会成为整个系统的瓶颈。

• 对应用最少量侵入

• 网站技术是为业务服务的，是否使用微服务需要根据业务发展规划，微服务也需要渐进式的演化，甚至会出现反复，即使用了微服务后又退回到集中式部署，微服务框架需要支持这种渐进式演化和反复。当然服务模板本身需要支持可集中式部署，也可分布式部署。

• 版本管理

• 为了应对快速变化的需求，服务版本升级不可避免，如果仅仅是服务实现升级，那么这种升级对服务请求者而言是透明的，无需关注。但是如果服务的访问接口发送变化，就需要服务请求者和服务提供者同时升级才不会导致服务调用失败。企业应用系统可以申请停机维护，同时升级接口，而网站服务不可能中断，需要服务提供者先升级接口，并同时提供历史版本的服务供请求者调用，当请求者访问接口升级后才可以关闭历史版本服务。

微服务框架（Dubbo）架构

Service Mesh 服务网格

Service Mesh Sidecar模式

• 复杂的场景才合适

微服务架构落地

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

• 先有独立的模块，后有分布式的服务。

• 业务耦合严重，逻辑复杂多变的系统进行微服务重构要谨慎。

• 要搞清楚实施微服务的目的是什么，业务复用？开发边界清晰？分布式集群提升性能？

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

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

• 更清晰的领域模型

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

• 查询服务不会修改数据，更好地保护数据。

事件溯源

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

• 利用时间溯源，可以精确复现任何用户状态，进行复核审计。

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

断路器

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

• 断路器三种状态：关闭、打开、半开。

服务重试及调用超时

上游调用者超时时间要大于下游调用者超时时间之和。

最重要的是需求