分布式微服务架构设计原理_读书笔记_1

Posted 2021-04-14 猿人课堂

第一章

1.2服务到微服务

1.2.3微服务架构与SOA服务化的对比

1. 目的

• SOA服务化设计的范围更广，强调不同的异构服务之间的协作和契约，强调有效继承，业务流程编排，历史应用集成等，典型代表Web Service和ESB

• 微服务使用一系列的微小服务来实现整体业务流程，目的是有效地拆分应用，实现敏捷开发和部署，每个微小服务团队里，减少跨团队的沟通，缩小变更和迭代影响的范围，单一微服务更容易水平扩展的目的。

2. 部署方式

• SOA服务化通常将朵儿业务通过组件化模式方式打包在一个战争包里，然后统一部署在一个应用服务器上。

• 微服务将完整的应用拆分成多个细小的服务，通常使用敏捷扩容，缩容的码头工人技术来实现自动化的容器管理，每个微服务运行在单一的进程内，微服务中的部署互相独立，互不影响。

3. 服务粒度

• 微服务倡导将服务拆分成更细的粒度，通过多个服务组合来实现业务流程的处理，拆分到职责单一，甚至不可再分。

• SOA对粒度没有要求，通常是粗粒度的，强调接口契约的规范化，内部实现可以更粗粒度。

1.3微服务架构的核心要点和实现原理

1.3.2微服务的去中心化治理

笔者曾经的工作平台：API网关统一了所有API入口，看起来很规范但是从技术角度讲，限制了API的多样性每个用户请求经过机房时只要有服务之间的交互，都会从API网关进行路由，服务上量以后，内部服务间的交互都叠加在API网关的调用上，很快遇到瓶颈

这个是典型的微服务反模式，微服务倡导去中心化治理，尽量不设置中心化的管理服务，最差也需要在中心化的管理服务宕机时有替代方案和设计，比如SOA服务化采用达博框架进行定制化，如果达博服务化出现了大面积的崩溃，则服务化系统会切换到点对点的麻袋远程调用，这被称为服务化降级，降级后点对点的麻袋远程调用时没有中心化节点，整体上符合微服务的原理。

1.3.3微服务的交互模式

1. 读者容错模式

2. 消费者驱动契约模式

• 服务契约分为提供者契约，消费者契约，消费者驱动的契约。

3. 去数据共享模式

   设计微服务架构时，一定不要共享缓存和数据库等资源，也不要使用总线模式，服务之间的通信和交互只能依赖定义良好的接口，通常使用RESTful样式的API或者通过RPC [远程过程调用，即远程过程调用]调用框架。

• 这种模式缺点：除了接口契约还存在数据存储契约。

• 上游数据格式发生变化时，可能导致下游的处理逻辑出现问题。

• 多个服务共享一个资源服务，对资源服务的运维难以划清职责和界限。

• 跨机房的服务调用不能使用独立的资源部署模式，因此难以实现服务自治。

• 微服务是去ESB总线，去中心化及分布式的

• SOA是ESB为核心实现遗留系统的集成，以及基于WebService的的的为标准实现的通用的面向服务的架构。在微服务领域，微服务之间的交互通过定义良好的接口来实现，不允许使用共享数据来实现。

• 实践过程中，有些方案使用缓存或数据库作为两个微服务之间的纽带，前一个服务将中间结果存入数据库或者缓存，下一个服务从缓存或数据库中拿出数据继续处理。