主要用于学习软件架构的演变, 分类, 以及各自优缺点与使用场景.

掌握使用不同的架构, 从而搭建高性能, 高并发稳定的服务.

1.文档阅读

微服务架构设计模式-aws 推荐.pdf –推荐, 后续放到github

微服务架构 – 学习/实践_william_n的博客-CSDN博客

01 分布式系统架构的冰与火_william_n的博客-CSDN博客

你真正思考过什么是架构吗pan style=”color:#7b7f82;”>– 20211027

15 | 兴趣与个人认知-极客时间

01 | 为什么需要消息队列客时间

2.整理输出

2.1 定义

图片可点击放大查看～ 

简单说：

计算机系统的软件架构师构建这个系统所需要的一组结构，包括软件元素，它们之间关系和两者的属性。

2.2 意义 

简单说：

就是为了非功能性需求，质量属性需求～

2.3 风格

分类: // 要解释 TBD

单体架构

SOA

微服务架构

分布式架构 

注意上面的名字，是有包含与重复的关系，

另外，关于最终的架构选择，见下面一句话

01 | 为什么需要消息队列客时间

所以我们说没有最好的架构，只有最适合的架构，根据目标业务的特点和自身条件选择合适的架构，才是体现一个架构师功力的地方。

2.4 架构的演进 

39 | 互联 技术演进的模式-极客时间

文字：

现在的公司应该算成熟期，虽然也面对着巨大的竞争压力，内部总结经历过几次大的架构阶段：第一代的大一统架构、第二代烟囱式架构、第三代分布式微服务架构、第四代的多地多中心架构以及现在正在进行的第五代架构升级。参与了多地多中心架构升级，也和腾讯的同学聊过，因而对异地多活有了一些定性认识，对于正在进行的第五代架构，还处于摸索阶段。

个人想法：

是否能说明，架构本身就是一个不断演进的过程，不存在终极的架构方式，而且业界似乎也并没有规范或者要求，其实更多的是企业自身的事情，你想怎么实现，怎么实现更好，怎么来。

后续补充

…

1. 你真正思考过什么是架构吗 阅读一番

https://mp.weixin.qq.com/s/aAvGK_kFOlYq_5KUs1Wi4Q

2. 关于架构的一些看法 — 单体架构与微服务架构

15 | 兴趣与个人认知-极客时间

极客时间：之前我们有聊到产研团队按领域划分的事情，饿了么之前的团队划分比较粗糙嘛，就是分 C 端和 B 端，C 端就是 APP 和 站，B 端就包括商户服务还有物流，你进去之后第一件事是做拆分，这里面其实就要用到逻辑思维。

张雪峰：饿了么原来就是个单体，所有的业务逻辑就是一个东西、一个源代码库，C 端、B 端、D 端（Delivery，物流）全在一起，牵一发动全身，也就是说你在部署的时候，每个服务器都要布一坨这个东西，一是影响性能，二是发布很麻烦。只要有同学发布，即使跟你无关，你也要发布一遍，所有的机器都要扫一遍。我们做技术的就要拆解，肯定要至少再分一级。拆分与否，我们当时就遵循一个原则：只要一个人有变化，一堆人要随着你动，或者叫“牵一发动大部分”的时候，这一定是有问题的。其实这也是逻辑原则或数学原则。所以我跟他们说，不要扯什么领域驱动、微服务了，就用这个原则。这个原则确实最容易讲清楚，但实践的时候要多次试、反复试。

单体是一个极端，微服务或单一原则是另一个极端。

饿了么从来没有真正提过微服务，从来没有过，我不去用这个概念。我们就是从业务的合理性去拆分。对领域驱动呢，我当时也是持观望态度，不能说保留态度，我觉得领域驱动是一个模棱两可的东西（顶尖 DDD 牛人或在大规模超复杂体系下成功实践过的同仁勿喷，毕竟让绝大部分技术同学吃透 DDD，无论 ROI 还是效率都很低），就跟架构一样，所以我希望回归朴素，就是从逻辑的角度，或者数学角度，给大家解释。所以当时我们也不做领域，我把以前的经验带过来，开始有一些中台的萌芽，比如说把交易系统、营销系统拆出来，把用户系统拆出来等等。从逻辑上讲，当你十次里面有八次“牵一发要动大部分”的时候，你就没必要去拆，你就让它耦合（内聚）在那，哪怕最后合出来一个巨大的东西，那证明这个业务就是这样的，没办法。你要么抱怨很倒霉进入这个业务领域，要么你就自己想办法克服。当然还有一个办法就是你通过技术去改革这个业务，那意味着这个业务甚至整个行业的游戏规则都要变，在短时间内几乎不可能。之前也讲过，对绝大部分公司的技术团队来说，妄图通过技术驱动业务，还是省省吧。

微服务架构设计模式-aws 推荐.pdf –推荐, 后续放到github

微服务架构 – 学习/实践_william_n的博客-CSDN博客 — 推荐

01 分布式系统架构的冰与火_william_n的博客-CSDN博客

01 | 为什么需要消息队列客时间