Architecture Phase1 Week10:Summarize

微服务架构用于庞大得系统得拆分，加快迭代测试部署效率。牢记技术为业务服务得点，合理得运用技术。

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

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

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

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

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

微服务得架构



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

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

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

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



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



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

更清晰的领域模型

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

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





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

断路器三种状态：关闭，打开，半开



最重要得还是需求：

微服务得网关。

DDD领域驱动设计。

组件内聚原则，高内聚低耦合。复用发布等同原则，版本号得约定建议。共同复用原则。



组件耦合原则。无循环依赖原则。稳定依赖原则。稳定抽象原则。