《微服务架构与实践》读书笔记二
目录
业务背景
微服务概念
微服务技术选型
微服务架构设计
微服务架构设计落地
微服务架构设计过程中积累的心得
总结
一、业务背景
1.1 产品现状
1、各产品系统独立开发，代码复用率低，系统之间互相调用，耦合严重，系统解耦独立部署困难。
2、传统的单体架构，规模越来越大也越来越笨重；当新功能的开发、功能的重构变得不再敏捷可控；测试者的回归测试边界难以琢磨；系统的上线部署也变的艰难
3、高并发访问下无法提供可靠性服务
4、持续集成、持续部署、持续交付等工程效率化工具严重缺失
5、监控系统、日志分析等系统稳定性工具严重缺失
以上种种情况，都让我们应对需求的变化而变得迟钝。
1.2 业务需求
架构肯定是为业务需求而生的，先来看看我们面对的业务需求及其特点。平台最主要满足两大类业务需求：面向餐饮企业在餐饮新零售下的经营和运营需求和面向产品及运营团队。
具体来看：
1、餐饮新零售下的餐饮企业经营和运营的痛点
如何提升营销能力和管理会员，以更低的成本为餐饮企业带来更多利润
如何对数据进行深度挖掘和分析，助力决策者进行运营决策
如何掌握实时数据，让决策者及时了解餐厅运营情况
2、面向产品及运营团队
主要是提升产品控制能力，促进整体系统的良好运转
因此开发SAAS服务的产品迫在眉睫，需要满足快速开发、灵活升级、高性能、高可用、高稳定、简化运维等更高的需求。
这一步的转型，不是"快"与"慢"，而是"生"与"死"。
二、微服务概念
专注于单一责任与功能独立运行的服务，模组化方式组合出大型应用。
2.1 特点
集中式架构：单体无分散
分布式架构：分散压力
微服务架构：分散能力
2.2 微服务架构优势
每个微服务组件都是简单灵活的，能够独立部署。不再像单体应用时代，应用需要一个庞大的应用服务器来支撑。
可以由一个小团队负责更专注专业，相应的也就更高效可靠。
微服务之间是松耦合的，微服务内部是高内聚的，每个微服务很容易按需扩展。
三、微服务技术选型和微服务的问题
3.1 技术选型
3.1.1 技术矩阵结论
- Netflix提供了比较全面的解决方案
- Spring Cloud对于Netflix的封装比较全面
- Spring Cloud基于Spring Boot，团队有基础
- Spring Cloud提供了Control Bus能够帮助实现监控埋点
- 业务应用部署在阿里云，Spring Cloud对12 Factors以及Cloud-Native的支持，有利于在云环境下使用
3.1.2 团队期望 - 首先支持Rest
- 团队技术栈和实例比较单薄，希望对新的技术平滑的学习曲线和能够Hold住
- 小团队，希望能够有一个比较全面的解决方案
- 目前团队主要采用Spring Cloud + Spring Boot的方式实现服务化
3.2 微服务带来的问题
依赖服务变更很难跟踪，其他团队的服务接口文档过期怎么办？依赖的服务没有准备好，如何验证我开发的功能。
部分模块重复构建，跨团队、跨系统、跨语言会有很多的重复建设。
微服务放大了分布式架构的系列问题，如分布式事务怎么处理？依赖服务不稳定怎么办？
运维复杂度陡增，如：部署物数量多、监控进程多导致整体运维复杂度提升。
上面这些问题我们应该都遇到过，并且总结形成了自己的一些解决方案，比如提供文档管理、服务治理、服务模拟的工具和框架； 实现统一认证、统一配置、统一日志框架、分布式汇总分析； 采用全局事务方案、采用异步模拟同步；搭建持续集成平台、统一监控平台等等。
微服务架构是一把双刃剑，虽然解决了集中式架构和分布式架构的问题，却带来了如上种种问题。因此我们是需要一个微服务应用平台才能整体性的解决这些问题。
四、微服务架构设计
4.1 微服务应用架构设计原则
4.2 微服务应用架构设计目标
微服务架构设计的目标，满足快速开发、灵活升级、高性能、高可用、高稳定、简化运维等更高的需求。
4.3 微服务应用总体架构
微服务应用平台的总体架构，主要是从开发集成、微服务运行容器与平台、运行时监控治理和外部渠道接入等维度来划分和考虑的。
- 开发集成：主要是搭建一个微服务平台需要具备的一些工具和仓库
- 运行时：要有微服务平台来提供一些基础能力和分布式的支撑能力，我们的微服务运行容器则会运行在这个平台之上。
- 监控治理：则是致力于在运行时能够对受管的微服务进行统一的监控、配置等能力。
- 服务网关： 则是负责与前端的WEB应用 移动APP 等渠道集成，对前端请求进行认证鉴权，然后路由转发。
4.4 微服务框架概览
五、微服务架构设计落地
5.1 基础环境
一个企业的IT建设非常重要的三大基础环境：团队协作环境、服务基础环境、IT基础设施。
- 团队协作环境：主要是DevOps领域的范畴，负责从需求到计划任务，团队协作，再到质量管理、持续集成和发布。
- 服务基础环境：指的是微服务应用平台，其目标主要就是要支撑微服务应用的设计开发测试，运行期的业务数据处理和应用的管理监控。
- IT基础设施：主要是各种运行环境支撑如IaaS (VM虚拟化)和CaaS (容器虚拟化)等实现方式。
5.2 服务通信
服务间的通信，往往采用HTTP+REST 和 RPC通信协议。
HTTP+REST，对服务约束完全靠提供者的自觉。 - 特点是简单，对开发使用友好。
- 缺点治理起来困难，连接的无状态，缺失多路复用、服务端推送等。
RPC对通信双方定义了数据约束。 - 连接大多基于长连接以获得性能的提升及附带的服务端推、调用链路监控埋点等，增强了系统的附加能力。
- 缺点是对调用端提出了新的要求。
综合来看，RPC从性能、契约优先来说具有优势，如何做到扬长避短呢？
引入GateWay层，让REST与RPC的优点进行融合，在GateWay层提供REST的接入能力。
5.3 服务注册/发现
以前的单体应用之间互相调用时配置个IP或域名就行了，但在微服务架构下，服务提供者会有很多，手工配置IP地址或域名又变成了一个耦合和繁琐的事情。那么服务自动注册发现的方案就解决了这个问题。
我们的服务注册发现能力是依赖SpringCloud Eureka组件实现的。服务在启动的时候，会将自己要发布的服务注册到服务注册中心；运行时，如果需要调用其他微服务的接口，那么就要先到注册中心获取服务提供者的地址，拿到地址后，通过微服务容器内部的简单负载均衡期进行路由用。
Eureka Server特点： - Eureka Client会缓存服务注册信息
- Eureka Server的注册信息只存储在内存中
- Eureka的注册只针对application级别，不支持更细粒度的服务注册，如单个服务Rest
- 服务每隔30秒向Eureka Server发送心跳，不建议修改心跳时间。Eureka用这个时间来判断集群内是否存在大范围的服务通信异常
- 如果在15分钟内有85%的服务没有被续约，则Eureka Server停止移除已注册的服务，以保障已注册的服务信息不丢失
- Eureka Server之间的数据同步，采用全量拉取，增量同步的方式
- Eureka 满足分布式事务中的CAP理论中的AP
5.4 集中式配置管理
微服务分布式环境下，一个系统拆分为很多个微服务，一定要告别运维手工修改配置配置的方式。需要采用集中配置管理的方式来提升运维的效率。
配置文件主要有运行前的静态配置和运行期的动态配置两种。 - 静态配置通常是在编译部署包之前设置好。
- 动态配置则是系统运行过程中需要调整的系统变量或者业务参数。
要想做到集中的配置管理，那么需要注意以下几点。 - 配置与介质分离，这个就需要通过制定规范的方式来控制。
- 配置的方式要统一，格式、读写方式、变更热更新的模式尽量统一，要采用统一的配置框架。
- 需要运行时需要有个配置中心来统一管理业务系统中的配置信息。
概念抽象：
介质，是源码编译后的产物与环境无关，多环境下应该是可以共用的如：jar
5.5 统一认证鉴权
安全认证方面，我们基于Spring Security OAuth2 + JWT做安全令牌，实现统一的安全认证与鉴权，使得微服务之间能够按需隔离和安全互通。
认证鉴权一定是个公共的服务，而不是多个系统各自建设。
5.6 分布式调用
微服务架构下，相对于传统部署方式，存在更多的分布式调用，那么“如何在不确定的环境中交付确定的服务”，这句话可以简单理解为，我所依赖的服务的可靠性是无法保证的情况下，我如何保证自己能够正常的提供服务，不被我依赖的其他服务拖垮？
我们采用的方案：
- 合理的超时时间
- 合理的重试机制
- 合理的异步机制
- 合理的限流机制（调用次数和频率）
- 合理的降级机制
- 合理的熔断机制
推荐SEDA架构来解决这个问题。
SEDA : staged event-driven architecture本质上就是采用分布式事件驱动的模式，用异步模拟来同步，无阻塞等待，再加上资源分配隔离结起来的一个解决方案。
5.7 分布式事务
分布式事务-CAP - C 分布式环境下多个节点的数据是否强一致
- A 分布式服务能一直保证可用状态
- P 网络分区的容错性
分布式事务-策略 - 避免跨库事务，尽可能相关表在同一个DB
- 2PC 3PC TCC 补偿模式等， 耗时且复杂
- 基于MQ的最终一致性 简单、高效、易于理解
- 将远程分布式事务拆解成一系列本地的事务
- 分布式事务-基于MQ
5.8 服务拆分
服务拆分方式