在2020年这个非同寻常的年份里面，自己与团队小伙伴一起利用周例会时间，分享学习了《架构整洁之道》系列内容，同团队一起学习成长。在这个岁末年终的日子里，来对自己本年度带领团队学习成长做个总结，分享给大家参考。

本文主要内容思路围绕以下几点：

• 通过系列学习分享，我们get到了什么？

• 我们搞这个系列的分享，初衷是什么？

• 通过系列分享，是否可以指导我们技术设计？

Part1：收获

1.1 《架构整洁之道》系列内容

主要内容总结一下，主要分以下几部分：

• 编程范式（结构化编程、面向对象编程和函数式编程）

• 设计原则（主要是SOLID）

• 组件处理（依赖、边界）

• 软件架构（其中讲了很多高屋建瓴的内容）

简单概况一下即包括 微观（代码层面）和宏观（架构层面）两个层面的主要开发技能。

1.2 “架构”到底是什么？

可能我们天天会说到“架构”，那它到底是什么呢？

软件架构（software architecture）

有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。-- 来自维基百科

系统其实是一群关联个体的组成，系统中的个体需要“根据某种规则”协作，架构需要明确这种协作规则。

架构＝骨架、结构，源于建筑学。

骨架 揭示架构中内在的支撑物；

结构 则表明架构关心支撑物相互结合的某种构造方式。

架构的价值是什么呢？

• 最少的人力成本满足构建和维护该系统的需求

• 支撑软件系统的全生命周期，让系统便于理解、易于修改、方便维护、轻松部署

1.3 “架构”的目的是什么？

架构设计的主要目的是为了解决软件系统复杂度带来的问题。

当明确了架构的目的之后，会有哪些好处？

主要对于“老鸟”架构师与“新手”架构师区分而言

• 心中有数，而不是一头雾水

• 有的放矢，而不是贪大求全

现实中我们还会遇到一些这样的讨论：

• “我们的系统一定要做到QPS 10w”

• “淘宝的架构就是这么做的，我们也要这样”

• “Docker现在很热，我们的架构应该将Docker引入进来”

影响我们做决策的首要依据应该是系统复杂度，那该如何分析呢？

1.4 复杂度主要分析点

系统复杂度主要分为以下几点：

• 高性能

  单机复杂度、集群复杂度

• 高可用

  计算高可用、存储高可用

• 可扩展性

  预测变化、应对变化

• 低成本

  创新（NoSQL、全文搜索引擎、Hadoop）

  Facebook HHVM、新浪微博 SSD Cache、LinkedIn Kafka

NoSQL为了解决关系型数据库无法对应高并发访问带来的访问压力

全文搜索引擎为了解决关系型数据库like检索低效的问题

Hadoop为了解决传统文件系统无法应对海量数据存储和计算的问题

• 安全性

  功能安全、架构安全

• 规模程度

量变引起质变

功能越多（数据越多），导致系统复杂度指数级上升

1.5 架构设计的原则有哪些？

同样的代码，不论是不是同一人写的，执行结果是确定的，但是同一个系统，不同的架构师，最终都可以解决问题，但设计方案却可能大不相同。

架构设计的原则主要是解决不确定性，也是优秀程序员与架构师区分点所在。

如何解决这种“不确定性”呢？

• 合适原则：合适优于业界领先

  将军难打无兵之仗（人手不足，却想产出多）

  罗马不是一天建成的（例如各大电商平台的“双11”抢购技术能力支持）

  冰山下面才是关键（没有业务场景，却幻想灵光一现）

• 简单原则：简单优于复杂

  结构复杂性（组件多，关联多，故障概率大，定位问题困难）

  逻辑复杂性（集所有功能于一身）

  《UNIX 编程艺术》KISS：Keep it Simple，Stupid!

• 演化原则：演化优于一步到位

  就软件而言，变化才是主题

  满足当前的业务需要

  应用过程中迭代，保留优秀，修复缺陷的设计，改正错误的设计

  业务变化时，扩展、重构，甚至重写

Part2：初衷

2.1 软件系统的价值

软件系统价值主要分为行为价值和架构价值。

• 业务价值（核心价值）

  需求的实现，以及业务可用性保障（功能性 bug 、性能、稳定性）

• 架构价值

  需求变更时，软件变更成本低且可控

事实表明，随着软件复杂度的上升，工程师人数随之增加，但是代码量到达一定量之后涨幅呈现缓慢。但是代码维护成本却呈指数级上升，同时工程师的生产效率也会随之降低，需求变更维护成本增大。

2.2 对程序员的简单分类

• 普通程序员

• 工程师

• 架构师

编写代码的方式有很多，只要能让程序跑起来，能正确地处理业务流程和对数据进行计算，就可以说“会编写代码”。

程序员需要熟悉整个程序的逻辑及处理过程，需要熟悉程序语言的特性，还需要熟悉一些计算机操作系统的交互调用方式，才能写出从用户侧交互，到数据和业务逻辑处理，再到与计算机系统交互的代码，有效地把用户信息、数据、业务和计算机串联和拼装出来。

还需要易读、易扩展、易维护，甚至可以直接重用。于是，这些人使用各种各样的手段和技术不断提高代码的易读性、可扩展性、可维护性和重用性。

2.3 我们的初衷

谈到我们学习《架构整洁之道》系列课程内容的初衷，其实即是回归软件系统的价值，利用多维的指导分析，帮我们做出正确的架构决策和架构设计。

Part3：收益

3.1 架构分类

我们需要针对当前业务需求，选择合适的应用架构，关于如何支持当前业务发展，如何面向未来，保证架构平滑过渡。

主要架构分类：

• 业务架构

  战略层面，业务方向是什么，要做什么；

• 应用架构

  战术层面，承上启下作用；

• 技术架构

  装备层面，负责业务的具体落地实施。

3.2 架构演进

架构的主要演进过程：

• 单体式架构

  俗称“烟囱式”架构

• 分布式架构

  按功能模块，服务化拆分

• SOA架构

• 微服务架构

其实无论哪种架构方式，在当时环境下都可以解决现实问题的，都具有一定的意义的。

总结起来还是那句话：存在即是合理的。

3.3 请求链路

除了系统架构本身，还需要关注每层技术架构的设计点。过程质量关乎整体质量，各环节的架构合理性至关重要。

3.4 编程之钻

编程之钻（The Programming Diamond）

上图描绘了编程作为一个完整工作流程（work process）的四项最基本活动

• 需求分析

• 设计实现

• 测试验证

• 调试纠错

我们开发任何一个软件功能、实现某个软件需求，一般都需要经历这 4 项基本的活动或状态。把这四个状态连起来恰好形成一个菱形，所以我把它叫作“编程之钻”（The Programming Diamond）。

犹如一颗大钻镶嵌了四颗小钻，把它们称作编程的“钻石”，也凸显了这几个基本任务及其相关技术与方法在软件开发、软件工程中的重要性。

Part4：总结

4.1 “悖论”？

通常我们在解决具体问题时候，最常见的想法就是快速的完成自己的工作任务，这样一来，是不是建设优质的软件架构形成了悖论呢？

4.2 观点

无论是微观世界的代码，还是宏观层面的架构，无论是编程范式还是微服务架构，它们都在解决一个问题：分离控制和逻辑。

所谓控制就是对程序流转的与业务逻辑无关的代码或系统的控制（如多线程、异步、服务发现、部署、弹性伸缩等），所谓逻辑则是实实在在的业务逻辑，是解决用户问题的逻辑。控制和逻辑构成了整体的软件复杂度，有效地分离控制和逻辑会让你的系统得到最大的简化。

其中 简单vs.简陋、平衡vs.妥协、迭代vs.半成品 就是我们需要涉及到软件架构中平衡的艺术。

4.3 学习建议

最后给大家一些学习上的建议：

• 1w小时学习定律

  不断的踩坑与填坑，会带给你真正的成长

• 关键点

  对技术的保持热情

  需要持续不断的精力投入

  坚持学习、实践、思考、总结

• 指导原则

  经验的沉淀与积累

  拓宽视野，不拘泥于现状

  锻炼深度思考能力，抓本质问题

以上为自己带领团队学习成长总结内容，在此分享给大家参考，其中不妥之处烦请指正，谢谢！

相信做难事者，必有所得！

Thanks for reading!