【架构】原理知识

参考：

软件架构：架构模式、特征及实践指南

中生代技术   https://developer.aliyun.com/article/658789?spm=a2c6h.12873581.technical-group.dArticle658789.55cc49afU2vUWK

微服务架构：https://martinfowler.com/articles/microservices.html

架构设计的哲学   https://cactus-proj.github.io/A-Philosophy-of-Software-Design-zh/

 

---

 

架构师看待事物的视角与开发人员是不同的--架构思维

架构思维：用架构的眼光或视角来看待事物。有四个重要的方面

1、要明白架构和设计之间的区别，了解如何与开发团队合作，进而使架构顺利落地

2、需要在具备技术广度同时，仍保持一定水平技术深度，支撑架构师觉察到其他人察觉不到的解决方案和可能性；

3、需要理解、分析和协调各种解决方案和技术之间的权衡

4、需要了解业务驱动的重要性及他们如何转化为架构问题的

 

传统架构和设计职责模型

• 架构师：分析业务需求以提取架构和定义架构特征，选择适合该问题域的架构模式和架构风格，以及创建组件，并将上述产出交给开发团队；

• 开发团队：负责每个组件创建类图、构建用户界面、开发和测试

     

 上图准确说明架构很难落地原因：穿越虚拟和实体转改的箭头是单向的。架构师决策常无法传达给开发团队，开发对架构改动也极少反馈给架构师。

为使架构落地，必须使架构师和开发团队之间形成双向的强关联：架构师和开发人员必须在同一虚拟团队中才能使架构落地。不仅促进双向频繁互动沟通，还促使架构师为开发提供指导和培训。

 开发和架构师对技术的侧重不同：

• 开发：拥有很深的技术深度；

• 架构师：非常广的技术广度才能像架构师般思考，并以架构的角度看待事物。

作为架构师，技术广度比技术深度更重要。所以需要牺牲技术深度来提升技术广度。

 从开发（聚焦技术深度）转变为架构师（聚焦技术广度）意味关键的改变，通常会导致2个常见的问题：

1、架构师试图在多个领域都保持专业深度，结果无一成功，并且深陷其中；

2、专业知识没有持续更新，常使用过时技术做决策；

 

---

如何系统的分析需求（从线和面的系统方法论，避免就事论事，从深度和广度上分析）

https://developer.aliyun.com/article/781608

1、避免如下问题（缺乏体系化的思考，"只见树木、不见森林"，没有从不同的维度上去思考问题，只是线性的思考，直接的表现就是【就事论事】，只把手头上的事情完成即可。）

• 场景简单：业务场景很简单，怎么也设计不出花儿来。
• 复杂度低：业务复杂度低，很难讲得出挑战来。
• 亮点少：运用的技术亮点少，基本上都是现有的中间件或框架来完成。
• 设计普通：方案缺乏新颖，业内也是这么做的，没有体现出自己的设计能力。

2、怎样证明技术方案是好的

大家去讲一个技术方案时，把背景、目标讲完之后，直接给出了技术方案，其实技术方案本身并不重要，重要的是你是怎么思考的，思考的过程非常重要，强调的是 WHY，HOW 很重要，但 WHY 更重要。这里有两个原则：

• 三段论：大提前、小提前、结论。一定要先讲大提前，它是一个有力的支撑，比如写议论文时，平时常写"鲁迅说过 xxxxx"，这个就是大提前；在技术方案设计上，就是要看业内的方案、业界的标杆在哪里，和它有什么不一样、创新了什么，一目了然，往往大家忽略了这个大提前，直接讲自己的方案，怎么证明你的就是好的呢？没有对比就没有感觉。

• 环境论：有时业内还没有具体的方案，或者是当下你的公司不适合业内顶配的方案，比如"中国特色社会主义"，它就是强调当前的环境，结合了具体的业务场景来权衡考虑的，并不是行业内的最优方案就是适合你的，方案的设计一定要有权衡、选择，设计出最适合当前环境的方案。

3、技术方案设计方法论：

本质论：强调的是透过现象看本质，这句话听起来是比较简单的，但要做到却是非常难的。看透本质至关重要，能让你真正把控事物的核心，我个人的一个方法是使用不超过 15 个字概括出事物的本质，因为本质的东西是简单的、美的、直揭主旨的，所以判断是否抓住了事物本质的一个标准就是用简单的话能否概括出事物的主旨。比如高并发，现在不再是一个新鲜的词汇，甚至大学生都知道怎么去做，缓存、异步操作、并行……，这些都是具体的措施，问高并发到底是什么，大家都能回答一些，比如流量大、系统压力大、用户多……，这些都是具体的特征，用一句话概括高并发：有限的资源应对大量的请求，概括出了高并发的根本特性，抓住了本质的东西就比较解决问题。带应届生的时候，我提到一个观点：工作三年以后，要能说得出 10 句对技术本质理解的话，提早给自己定下目标，在平时中积累一些思考和沉淀。

针对高并发（本质：有限的资源应对大量的请求）的体系化思考：站在矛盾的双发，从2个维度去思考（见下图）

• 高可用场景：即使在极端条件下，强调系统的可用性。

• 高扩展场景：如何应对变化的问题，以最少的代价支撑业务发展。

• 分布式一致性场景：一致性问题在分布式场景下经常遇到，选用哪种技术方案要结合当前的业务、条件来选择。

• 高性能场景：快速地处理请求。

 

矛盾论：揭示的是事物之间的矛盾，矛盾是推动事物不断发展的动力，一般从事物本质中，可以看到一些矛盾出来，比如上面高并发的本质是有限的资源应对大量的请求，有限对大量本身就是一对矛盾，找到了矛盾就去解决矛盾，解决的一个方向就是平衡矛盾，矛盾解决了，问题自然就解决了，比如现在资源是大量的，完全可以应对大量的请求，这样高并发的场景对于你来讲就不是一个问题。

系统论：从系统各个要素出发，多维度思考问题，最为简单的是从矛盾双方出发思考问题，比如有限的资源，能不能让资源的数量变多呢？能不能提升资源的处理能力呢？……，从这些方向去思考，思路就一下子打开了，所谓的缓存等常说的方法只是一个个具体的解决手段，我们需要更加立体、多维的解决思路，再结合具体的场景、现状组合一些解决方法。

演进论：强调事物是进化的，符合事物的发展规律和人的认识，有可能我们想得非常完善，不可能等所有的事情都做好了再上线，得有计划、分阶段地解决问题，优先解决主要矛盾、核心诉求。也有可能经过一段时间之后，事物的主要矛盾发生了变化，我们的方案也得演进式设计。

  

复杂系统设计原则与案例

https://developer.aliyun.com/article/1262579?spm=a2c6h.13262185.profile.5.50d8439eORlsRJ

系统架构系列文章

https://www.infoq.cn/article/1w2mjzzx-0dm9j9vysam

  

识别架构特征

架构特征：质量属性、非功能性能；如可配置性，可维护性等

架构特征的来源

1、领域问题中提取

 2、从需求中提取：

 

架构风格

反模式：Big Ball of Mud，大泥球，缺少可识别的架构结构

 

 

架构风格划分：