《极客时间-架构实战案例解析》读书笔记

1. 站在系统整体的角度考虑问题；不仅要从技术的角度考虑问题，也要从业务的角度来考虑问题，深入理解系统的挑战在哪；做好各方面的平衡，在各项资源的约束下，寻求一个最优解。

2. 架构的出发点是业务和技术在不断复杂化，引起系统混乱，需要通过架构来保证有序。

3. 架构实现从无序到有序，是通过合理的内部编排实现的，基本的手段，就是“分”与“合”，先把系统打散，然后将它们重新组合，形成更合理的关系。

   1. “分”就是把系统拆分为各个子系统、模块、组件。

   2. “合”就是基于业务流程和技术手段，把各个组件有机整合在一起。

4. 业务架构、系统架构、技术架构

   1. 业务架构就是讲清楚核心业务的处理过程，定义各个业务模块的相互关系，它从概念层面帮助我们理解系统面临哪些问题以及如何处理；

   2. 应用架构就是讲清楚系统内部是怎么组织的，有哪些应用，相互间是怎么调用的，它从逻辑层面帮助我们理解系统内部是如何分工与协作的。

   3. 技术架构就是讲清楚系统由哪些硬件、操作系统和中间件组成，它们是如何和我们开发的应用一起配合，应对各种异常情况，保持系统的稳定可用。所以，技术架构从物理层面帮助我们理解系统是如何构造的，以及如何解决稳定性的问题。

5. 一个好的架构设计既要满足业务的可扩展、可复用；也要满足系统的高可用、高性能和可伸缩，并尽量采用低成本的方式落地。所以，对架构设计来说，技术和业务两手都要抓，两手都要硬。

6. 产品经理是站在用户的角度进行需求分析，而业务架构师是站在开发者的角度定义系统内部结构。

7. 业务架构扩展性的本质是：通过构建合理的模块体系，有效地控制系统复杂度，最小化业务变化引起的系统调整。

8. 通过拆分，实现模块划分（水平拆分-按功能、垂直拆分-按业务）；通过整合，优化模块依赖关系（通用化、平台化）。

   1. 通过模块通用化，模块的数量减少了，模块的定位更清晰，概念更完整，职责更聚焦。在实践中，当不同业务线对某个功能需求比较类似时，我们经常会使用这个手段。

   2. 业务平台化是模块依赖关系层次化的一个特例，只是它偏向于基础能力，在实践中，当业务线很多，业务规则很复杂时，我们经常把底层业务能力抽取出来，进行平台化处理。

9. 微服务是去中心化的，不需要SOA架构中ESB的集中管理方式。在实践中，我们往往弱化微服务的小应用定位，然后扩大化微服务小服务的定位，我们不再强调端到端的业务封装，而是可以有各种类型的微服务。我们需要对服务依赖关系进行有效的管理，打造一个有序的微服务体系。否则的话，东一个服务，西一个服务，这样会让系统变得碎片化，难以维护和扩展。

10. 中台通过实现基础业务的平台化，实现了企业级业务能力的快速复用。

11. 在微服务架构下，我们搭建的是一个个离散的服务，如商品服务、订单服务等等。而在中台里，这些微服务升级为了商品中心、订单中心，每个中心更强调体系化，包括更好的业务通用能力，更好的系统运营能力（如监控、稳定性、性能的强化），更好的业务运营能力（比如商品中心自带配套的商品管理后台）。每个服务中心都围绕核心业务，自成体系，成为一个微内核，这些微内核形成一个有机整体，共同构成了基础业务平台，也就是中台。松散的微服务->共享服务体系->中台，这是微服务架构向中台架构的演进过程。

12. 典型的业务中台的结构。它一般包含三层，从上到下分别是通用聚合服务层、通用基础业务平台和通用中间件平台。

13. 整个中台架构从上到下分为四个层次：

    1. 渠道&应用层，这是整个系统的对外部分，包括了各个应用的前端，如App、小程序、公众号等等，这些是需要定制的部分。同时，在对外部分，我们还会提供Open API，供上下游企业调用。

    2. 应用平台是各个具体应用的母体，它包含了各个应用的服务端，比如小程序服务端、App服务端等等，这些服务端会针对具体场景，做流程编排和信息的聚合。

       服务端和前端之间还有一个网关，网关实现前后端隔离，具体负责外部访问的安全验证和监控，以及内外部请求的路由和消息格式转换。

    3. 业务中台是中台架构的核心，它包括一系列的通用基础服务，以及它上面的通用聚合服务和下面的技术平台，

    4. 后台包括两部分，第一部分是适配插件，用于连接商户内部系统和中台基础服务，比如，在中台的商品服务和后台ERP之间同步商品数据，在中台的会员服务和后台CRM之间同步会员信息。一般针对每个内部系统，都有一个适配插件，它起到了类似硬件驱动程序的作用，这个一般是定制化的。第二部分是企业内部系统，这个是企业的IT基础设施，业务最终会在这里落地。

14. 中台代表了企业核心的业务能力，它自成体系，能够为C端的互联网场景提供通用的能力，并通过各种插件和后台打通。

15. 复用有多种形式，它可以分为技术复用和业务复用两大类。技术复用包括代码复用和技术组件复用；业务复用包括业务实体复用、业务流程复用和产品复用。从复用的程度来看，从高到低，我们可以依次划分为产品复用>业务流程复用>业务实体复用>组件复用>代码复用。业务上的复用比纯粹的技术复用有更高的价值，我们要尽量往这个方向上靠。

    1. 代码复用：代码库、SDK等。组件复用：中间件等。都属于工具层面的复用。

    2. 业务实体复用针对细分的业务领域，比如订单、商品、用户等领域。它对各个业务领域的数据和业务规则进行封装，将它变成上层应用系统可以直接使用的业务组件。

    3. 业务流程的复用针对的是业务场景，它可以把多个业务实体串起来，完成一个端到端的任务。比如说，下单流程需要访问会员、商品、订单、库存等多个业务，如果我们把这些调用逻辑封装为一个下单流程服务，那下单页面就可以调用这个流程服务来完成下单，而不需要去深入了解下单的具体过程。相比单个的业务实体复用，业务流程的复用程度更高，业务价值也更大。

    4. 最高层次的复用是对整个系统的复用，比如说一个SaaS系统（Software-as-a-Service），它在内部做了各种通用化设计，允许我们通过各种参数配置，得到我们想要的功能；或者说一个PaaS（Platform-as-a-Service）平台，它会提供可编程的插件化支持，允许我们“嵌入”外部代码，实现想要的功能。

16. 从技术复用到业务复用，越往上，复用程度越高，复用产生的价值也越大，但实现起来也越复杂，它能复用的场景就越有限。

17. 要实现业务上的复用，一个比较可行的做法是，把各个基础业务封装成共享服务，供上层所有应用调用。落地基础服务是实现业务复用的有效方式。

18. 基础服务边界划分：要解决“我是谁”的问题，它实现了服务和周边环境的清晰切割。

    1. 服务的完整性原则：当你在划分服务边界时，要保证服务数据完整、功能全面，这样才能支撑一个完整的业务领域。

    2. 服务的一致性原则：服务的数据和职责要一致，谁拥有信息，谁就负责提供相应的功能。

    3. 正交原则：基础服务之间不会有任何的调用关系正交还有另外一种情况：服务之间有数据的依赖关系，但没有接口的调用关系。

19. 共享服务落地：服务边界划分，功能抽象，以订单服务为例：

    1. 边界：不主动调用其他服务，不和三方系统集成，不提供优惠计算/成本分摊功能，不提供履约信息。

    2. 内部功能：订单状态通用化（主状态+子状态，主状态订单服务负责，子状态业务系统维护），订单服务接口定义：同步接口（分使用场景返回字段）、异步消息（胖消息、瘦消息）。

20. 现有微服务改造：

    1. 准备阶段：圈表（确定服务的数据模型）、收集SQL、SQL拆分

    2. 实施阶段：服务开发、服务接入、独立数据库 ·

21. 对现有系统的改造，服务的边界划分主要是从圈表入手的，而不是从一个服务应该有哪些功能入手的，这一点和新服务设计是有所不同的。不能追求理想化和一步到位，而是要考虑到系统的平滑过渡，先实现微服务的顺利落地，后续再考虑各种优化。除了做好服务本身的设计开发工作，相关团队之间的配合也是非常重要的。

    1. 一方面，如果确定了服务包含哪些表，也就大致确定了服务有哪些功能，而表是现成的，它比业务功能要直观很多，所以从表入手比较高效；

    2. 另一方面，如果从表入手，构造的服务和表是对应的，服务包含的是完整的表，不会产生一个表的一部分字段属于库存服务，而另一部分字段属于别的服务的情况，避免表字段的拆分带来额外的复杂性。

22. 通过构建这样一系列的共享服务，我们就实现了各个渠道业务规则和业务数据的统一管理，最终我们落地了一个强大的业务中台，可以很方便地扩展各个业务，实现企业整体业务能力的复用。

23. 业务架构解决的是系统功能性问题，更多的是从人出发，去更好地理解系统；而技术架构解决的是系统非功能性问题，在识别出业务上的性能、可用性等挑战后，更多的是从软硬件节点的处理能力出发，通过合理的技术选型和搭配，最终实现系统的高可用、高性能和可伸缩等目标。

24. 系统故障点总结起来有三种：资源不可用、资源不足、节点的功能有问题。

25. 高可用策略：避免发生，转移故障，降低影响，快速恢复。处理线上故障的首要原则是先尽快恢复业务，而不是定位问题，通过解决问题恢复系统。

26. 高可用架构原则：正面保障、减少损失、做好监控。

    1. 正面保证：冗余无单点（针对节点本身故障）、水平扩展（针对节点处理能力不足）。

    2. 减少损失：柔性事务（保证系统基本可用和数据最终一致性）、系统可降级（限流、降级、熔断、功能禁用）

    3. 做好监控：系统可监控

27. 高可用手段：CND缓存、HA高可用、通信线路备份、服务实例水平扩展、数据库分库分表、消息异步解耦、缓存、一体化监控；通过压测确保系统可支撑的QPS和系统可用性指标。

28. 监控分类：从接入层、应用系统、中间件、基础设施几部分考虑，分为用户体验监控、业务监控、应用监控、中间件监控、基础平台监控。碎片化的监控方式，处理线上问题很低效，无法快速定位问题，将系统所有监控信息串联起来，以直观的形式展现，可快速识别问题点及问题原因。（根因分析）

29. 高性能的策略和手段：

    1. 加快单个请求处理：优化处理路径上每个节点的处理速度、并行处理单个请求（拆分多个子请求，如MapReduce）。

    2. 同时处理多个请求：多节点、多进程、多线程。

    3. 请求处理异步化：MQ消息等。

30. 在考虑系统高性能保障的时候，首先需要考虑提升单个请求的处理速度，然后再考虑多请求的并发处理，最后通过异步化，为系统争取更长的处理时间。

31. 可伸缩的策略和手段

    1. 节点级别可伸缩：无状态节-增删节点，弹性伸缩；有状态-状态数据重新分布。

    2. 系统级别可伸缩：系统端到端的伸缩，同时对多个节点进行伸缩处理。（Set化）

32. 高性能和可伸缩架构原则：可水平拆分和无状态、短事务和柔性事务、数据可缓存、计算可并行、可异步处理、虚拟化和容器化。

33. 秒杀系统设计：异步化思路：接收前端下单请求，后端不实时生成订单，放入队列，异步生成订单，前端展示订单时生成排队情况。（先到先得，符合公平原则）

    1. 队列：Redis（可获取队列长度、队列中的位置）、每个商品一个单独队列（1次只能秒杀1个商品）、人数多的队列优先调度执行、队列长度（和秒杀库存一致，达到上限，前端请求不再放入队列）

    2. 设计常规流程和秒杀流程，互相隔离；秒杀商品和常规商品隔离（读写频率不一样）。

34. 分库分表：路由字段的选择和设计（主维度、辅维度）、分库分表数量的确定、特殊查询场景支持（跨库查询、分页等）。

35. 电商系统技术架构演进：

    1. 单体系统：一个代码仓库、一个数据库，负载均衡访问。（开发效率低）

    2. SOA架构：拆分交易系统、账户系统，一个数据库，系统间通过中心化负载均衡访问。（负载均衡存在单点问题）

    3. 服务调用去中心化：引入注册中心。（单数据库性能和容量问题）

    4. 垂直分库：交易系统数据库、账户系统数据库。（数据库单实例问题）

    5. 水平分库及高可用部署：水平拆分-分库分表，缓存、MHA高可用（单节点故障Failover、读写分离）。（机房故障）

    6. 多机房部署：一个注册中心（跨机房调用耗时）

    7. 服务调用本地化：每个机房一个注册中心，跨机房访问数据库。（下游服务可用性影响主流程）

    8. 依赖分级管理：强弱依赖治理，异步消息。（单机房故障）

    9. 多机房独立部署：每个机房独立资源，包括注册中心、服务、数据库，Set化。

36. 架构落地：了解业务（产品经理、业务人员）、了解系统（开发）、系统串联（草根方案）、方案升华（通用化）、方案简化（可落地）、方案宣讲（实施跟踪）。

37. 架构师成长路径：初级开发、高级开发、架构师、大师。

    1. 深入了解网络通信、了解底层系统、熟练掌握各种设计工具和方法论。（端到端的角度进行业务分析和系统设计）