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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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