正文共： 3166字 10图 预计阅读时间： 8分钟程序员
在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小时学习定律
不断的踩坑与填坑，会带给你真正的成长
-
关键点
对技术的保持热情
须要持续不断的精力投入
坚持学习、实践、思考、总结
-
指导原则
经验的沉淀与积累
拓宽视野，不拘泥于现状
锻炼深度思考能力，抓本质问题
你们好，我是「架构精进之路」公号做者 flyer0126，公号文章主要来自于我的平常工做问题总结思考，相信问题及解决方案均具备普适性，但愿同你们一块儿学习成长。
你们若有任何疑问/困惑，可关注公号回复关键字 “wx” 添加我的微信，继续勾搭~
「技术架构精进」专一架构研究，技术分享
Thanks for reading!
本文分享自微信公众号 - 架构精进之路（jiagou_jingjin）。
若有侵权，请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”，欢迎正在阅读的你也加入，一块儿分享。