读书笔记-SpringCloudAlibaba微服务原理与实战-谭锋-【未完
待续】
SpringCloudAlibaba微服务原理与实战谭锋电⼦⼯业出版社
ISBN-9787121388248
仅供参考, ⾃建索引, 以备后查
⼀、应⽤架构演进、微服务发展史
1.单体架构
⼀般来说，如果⼀个WAR包或JAR包就能包含⼀个应⽤程序的所有功能，我们就称其为 单体架构。早期互联⽹公司或创业型公司中，这种架构由于⾜够简单，能够快速开发上线，且初期⽤户量不⼤，单体架构⾜以满⾜业务的正常运⾏。
2.集及垂直化
若应⽤程序需要长期运营，则单体架构⾯临了诸多挑战，⽤户量增⼤，服务器负载增⼤，业务场景越来越复杂。慢慢的，服务器的响应会越来越慢。⽽且单体架构中，随着业务复杂程序的提升，业务之间的耦合度越来越⾼，对代码维护和升级等也愈发困难。
此时，可以横向扩展，即增加服务器，单台变集；或者把业务拆分，减少耦合度，即增加Tomcat服务器，变为服务集，每个Tomcat服务器包含⼀个或多个业务⼦系统；同时拆分数据库，分库分表。
3.SOA (Service-Oriented Architecture) ⾯向服务架构
在上⾯介绍的集模式中，各个业务在⼀个或多个Tomcat服务器中，但是业务之间存在调⽤关系，则会存在这么多检查逻辑，共享业务等，这些都会产⽣⾮常多的冗余代码。
针对以上问题，SOA架构应运⽽⽣，它和 ⾯向过程、⾯向对象、⾯向组件的思想⼀致，是利⽤软件组建及开发的⽅式。SOA架构⽬标是把通⽤的，会被上层服务调⽤的共享业务提取封装为基础服务，这些基础服务可以被重⽤且相对独⽴。总体来说，SOA架构解决信息孤岛，增强了共享业务的重⽤。
分布式和微服务的关系4.微服务架构
泛泛来讲，微服务是SOA的⼦集，对可重⽤业务服务的进⼀步优化，即把服务拆分的更加细化，如原本10个服务（模块）拆分为100个微服务（模块）。不过⼀旦如此，服务的构建、发布及运维复杂度也会成倍增加，所以微服务的前提是 软件交付链路 及 基础设施的成熟。在此书作者来看，微服务是SOA服务化思想的最佳实践。
SOA关注点在于服务的重⽤及解决信息孤岛；⽽微服务关注的是解耦，虽然特定程序上来说，解耦和重⽤类似；另外，微服务更多的关注于应⽤的版本更新，持续交付；同时，由于服务粒度细化，开发运维更加重要，所以为了避免运⾏环境的⼀致性问题，微服务与容器技术关联的更加紧密。
业务构建为可独⽴运⾏的微服务后，每个微服务仅关⼼某个特定功能，服务之间采⽤RESULT API通信。开发⼈员更加能关注某个特定业务，如注册服务等。
微服务的优势：
复杂度可控：⼀句话来讲，就是拆分颗粒度，细化到极致还是达到某种程序；
技术灵活度：只需要遵循对外接⼝访问规则，每个微服务的实现⾃由度⾼；
可扩展性强：单个微服务可以保留⼀个，亦可以作为集来部署；
独⽴部署：微服务单独运⾏，不影响到其它业务；
容错性：若某个微服务故障，调⽤者可以重试、降级、熔断等或默认返回调⽤结果。
⾯临的挑战：
微服务并不能解决所有问题，虽然本⾝优势⼈多，但也带来了诸多挑战。如：数据库如何拆分、API交互、开发维护和运维等。更多的是如下问题：
故障排查：⼀个请求可能会调⽤数个微服务，交互链路复杂，若要定位故障位置⽐较困难；
服务监控：单体架构中很容易实现监控，毕竟所有功能集中在⼀起。⽽微服务架构中，服务监控⽐较复杂，成千上万个微服务需要监控，性能开销较⼤；
分布式架构的复杂性：微服务其实也是⼀个分布式系统，涉及到各个服务之间的远程通信，所以通信的弊病，⽹络延迟和⽹络故障是很淘宝⽹的；
服务之间的依赖：服务之间的调⽤问题，若依赖较多，则系统调⽤显⽽易见的会复杂的多；
运维成本：保证成千上万微服务正常⽀⾏，挑战巨⼤，如：快速扩容、单点故障、快速部署和统⼀管理等。
典型的微服务架构：
除了图中提到的，还需要考虑：分布式配置中⼼、服务路由、负载均衡、熔断限流和链路监控等
⼆、SpringCloud简介
Spring Cloud 简述
微服务架构最先考虑的是服务间的远程通信问题，⽬前有许多的RPC框架，如 Thrift、Dubbo、Motan、gPRC等。接着要考虑服务之间的动态感知，总不能硬编码调⽤地址吧。由于此类问题浮现，最终在2015年诞⽣了SpringCloud，⽬前流⾏的版本有 Spring Cloud Netflix 、 Spring Cloud Alibaba 和 Spring Cloud Consul。
SpringCloud主要致⼒于解决如下问题：
Distributed/versioned configuration 分布式及版本配置；
Service registration and discovery 服务的注册与发现；
Routing 服务路由；
Service-to-service calls 服务间的调⽤；
Load balancing 负载均衡；
Circuit Breakers 熔断；
Global locks 全局锁；
Leadership election and cluster state 主服务的选举及集状态；
Distributed messaging 分布式消息。
SpringCloud并不是全新研发的框架，⽽是根据相应的规范整合了⼀些已经存在且⽐较优秀的开源框架，结合SpringBoot屏蔽掉了每个框架的复杂配置，开发者可以快速上⼿使⽤。事实上，SpringCloud是⼀套规范。
SpringCloud版本的全名规则不同以往，⽽是采⽤了伦敦地铁站的名字来定义。⽽且，⼤版本号后⾯多了 .SRX 字样，其中SR为Service Release，X为递增的数字，每当更新内容积累到⼀定程序或修复了Bug后，会增加X来发布新版本。
除此之外，SpringCloud依赖SpringBoot，所以需要在使⽤时注意相应的版本。
Spring团队最厉害的地⽅是他们很少造轮⼦，这是作者的有的话。Spring Framework最核⼼的功能是IoC和AOP，对于ORM、MVC等，Spring都提供了⾮常好的兼容性，如Hibernate、MyBatis、Struts2。⽽SpringMVC是由于考虑到Struts2的安全漏洞才造出来的，同样的还有Spring Cloud Gateway，来取代Zuul⽹关的。
⽬前最主要的两个SpringCloud解决⽅案是Spring Cloud Netflix和Spring Cloud Alibaba。
Spring Cloud Netflix 解决⽅案
SpringCloud Netflix的微服务框架包含了如下组件：
Eureka 服务注册与发现；
Zuul 服务⽹关；
Ribbon 负载均衡；
Feign 远程服务的客户端代理；
Hystrix 断路器，服务熔断和限流功能；
Hystrix Dashboard 监控⾯板；
Turbine 聚合管理各个服务上的Hystrix监控信息。
Spring Cloud Netflix是SpringBoot和Netflix OSS （Netflix Open Source Software）在Spring Cloud规
范下的产物，⽽Eureka、Zuul等都是Netflix OSS的开源组件。不过有些组件已被标记为维护模式，将不会再有重⼤功能更新，只会修复bug及安全问题，如：Spring-Cloud-Netflix-Hystrix、Spring-Cloud-Netflix-Ribbon和Spring-Cloud-Netflix-Zuul等。
Spring Cloud Alibaba 解决⽅案
Spring Cloud Alibaba是阿⾥巴巴集团下的开源组件和云产品在Spring Cloud规范下的实现，主要组件如下：Sentinel 流量控制和服务降级；
Nacos 服务注册与发现、分布式配置中⼼；
RocketMQ 消息驱动、消息队列；
Seate 分布式事务；
Dubbo RPC通信；
OSS 阿⾥云对象存储（收费云服务）。
优势：
相对于 Spring Cloud Netflix，Alibaba的优势主要有两点。Alibaba的开源组件，在实现Spring Cloud规范之前就已经被各⼤公司使⽤，所以可以让开发者轻松实现技术整合与迁移。如Dubbo早就⽀持了多种通信，迁移不会投⼊太多成本。另外，由于经历数次双11的考验，所以Alibaba的开源组件在服务治理及⾼并发处理上有天然优势。
三、SpringBoot、⾃动装配、⾃定义Starter
四、ZooKeeper、 Dubbo （Dubbo、Apache Dubbo、Dubbo Spring Cloud）
五、Nacos服务注册发现
六、Nacos配置管理
七、Sentinel微服务限流及熔断
⼋、分布式事务
数据库事务：从事务开始到结束的所有数据库操作，要么同时成功，要么同时失败。
ACID：原⼦性 Atomicity ⼀致性 Consistency 隔离性 Isolation 持久性 Durability
分布式事务应⽤场景：单体数据库纵向拆分为多个平⾏的数据库后，由于数据库事务仅⽀持单个数据库，当需要对多库实现事务时，需⽤到分布式事务
分布式事务问题也叫 分布式数据⼀致性问题，实际应⽤中，就尽可能从设计层避免分布式事务问题
X/Open 分布式事务模型 2PC
X/Open DTP (X/Open Distributed Transaction Processing Reference Model)
两阶段提交(2PC, Two-Phase-Commit)，包含有三种⾓⾊：
1. AP：Application ⽤户应⽤程序
2. RM：Resource Manager 资源管理器，即数据库等
3. TM：Transaction Manager 事务管理器，事务协调者，为AP提供编程接⼝管理RM等。类似于 Spring 中 Transaction Manager
RM 注册到 TM，AP 从 TM 申请 RM 连接，⽣成全局事务并获取 XID。之后 AP 加⼊ XID 参数执⾏操作，事务结束，TM 通知事务结束并根据 RM 执⾏结果执⾏提交或回滚操作。TM 与 多个 RM 之间的
事务控制是基于 XA (XA Specification) 协议来完成的，Oracle、MySQL、DB2 实现了此 XA 协议接⼝。
两阶段提交 2PC：
1. 准备阶段：TM 通知 RM 准备分⽀事务，记录事务⽇志，反馈准备结果
2. 提交/回滚阶段：任何⼀个 RM 执⾏失败则回滚，全部成功才提交
缺点：
同步阻塞：所有参与者 RM 阻塞等待下⼀步指令
过于保守：任何⼀个 RM 结点失败就回滚
TM单点故障：若 TM 故障则所有 RM 参与者会⼀直锁定
数据不⼀致：多个 RM 在最后提交阶段出现局部故障
三阶段提交（加⼊超时机制，避免资源永久锁定）
1. CanCommit 询问阶段：TM 询问 RM 是否可以执⾏指令
2. PreCommit 准备阶段：TM 向 RM 发起 PreCommit 请求，RM 执⾏操作并写⼊ redo 和 undo ⽇志，等待下⼀步指令
3. DoCommit 提交/回滚阶段：根据上⼀阶段执⾏结果告知 RM 执⾏ 提交或回滚 操作
CAP定理
CAP定理，⼜名 布鲁乐定理。 简单来说指：在分布式系统中不能同时满⾜ ⼀致性 Consistency、可⽤性 Availability 和 分区容错性Partition Tolerance，最多同时满⾜两个，如满⾜ CP 或 AP，不可能实现 CAP 或 CA。原因是 ⽹络通信 不是绝对可靠，⽹络延时、⽹络异常时常发⽣。
C：数据在多个副本中保持强⼀致，如主从数据库
A：系统对外提供访问，任何时候都能获得响应
P：分布式系统中遇到分区故障，系统仍能正常对外提供服务
CP 模式：两阶段与三阶段提交就是采⽤这种⽅案，可能导致⽤户完成操作需要等待较长时间的问题
AP 模式：放弃强⼀致，运⽤其它技术实现最终⼀致，AP 模式是解决分布式数据⼀致性问题的主要选择
BASE理论

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。