大家好，我是杰哥
无意中在书架上拿到一本书 - 《从零开始学架构-照着做，你也能成为架构师》。这本书在书架上放了很久。看着书名，感觉像是一本灌水书，所以一直都没有翻过，但那天实在闲来无事，手头一时又没有什么其他的书可以看，就拿过来读了读
没有想到，仔细一读，发现还写得真不错。看得出来作者李运华是一位实战经验颇丰的架构师前辈，所以能够通过通俗易懂的语言与贴切的案例，为你讲清楚架构设计的设计思路与方法
当天晚上读完第一章就被吸引住了。他站在全局的视角，总结出一些常用架构设计的设计思路与方法，与自己工作中的某些想法不谋而合，让本人的很多认知也都系统地梳理了一遍，并且有一种融会贯通的感觉。而全书的中心思想 - ”架构设计的主要目的：为了解决复杂度带来的问题“，则让我醍醐灌顶
一、读书笔记
以下是书中的基本重点目录，我专门梳理了一遍 架构设计读书笔记.png
此外，还有几个采用真正的实例，围绕着前面这些技术点做的介绍，也有很多新的东西，交给大家自己去看了~
二、开悟的点
总体来说，这本书，对我来说，温故知新的有以下几点：
1、负载均衡策略的使用场景
2、SOA架构 - ESB
3、微服务的坑与最佳实践
加深了我的认知的有：
1、合适原则-架构师需要深入了解业务
2、架构师需要具备一定的技术基础、业务沉淀、分析能力、沟通能力以及决断力
可借鉴的为： FMEA思路
具体来讲，以下几点对我印象还是比较深的：
1、架构设计，最重要的是什么？
我更加肯定了，要做好一个好的架构设计，最重要的在于对业务的理解要透彻，具体体现在以下两点：
1）对业务本身有一定的理解，识别出核心业务
2）识别出业务本身的复杂度-最关注的质量属性，如高可用、高性能等
2、确定方向：识别出复杂度的优先级
通过对需求的分析，你已经罗列出来了这个项目需要关注的多个复杂度，比如高可用、高性能、可扩展、易维护、成本低等等，在这一步，则需要排列出最高优先级的复杂度了。
需要确定这个系统最关键的是需要解决哪个复杂度：只有解决了这个复杂度，这个项目的价值才会真正达到。
在实践过程中，你会发现，往往只要多引入一个组件，或者多实现一个功能，引来的复杂度与工作量可不是只增加一倍，而是成倍增加，甚至成量级增加。因此识别出业务的复杂度优先级，把劲使在刀刃上，只关心优先级最高的前几个复杂度，变得至关重要
对于当前业务不那么关心的复杂度，千万不要用花太多成本与精力去解决它，而是采用其他比较简单的方案，使其得到缓解。比如说对于一个追求高可用的系统，不一定非要实现绝对的数据一致性，就可以采用在分区期间记录日志，当发故障解决之后，采用这些日志进行恢复的的方案实现数据的最终一致性也是可以接受的。
因此，识别出复杂度的优先级，也就是说当前整个业务的质量属性的优先级，是比较关键的，它是确定最终目标的一步。后续的步骤，都是围绕着这个目标来进行的。只有目标定得准确且明确，后续才不会偏离方向，做决策的时候也不会很困难
3、备选方案的设计
对于备选方案的设计，需要有一定的技术或者经验储备，并且能够具备比较开放的思想
每种技术或者方案出现都有一定的道理，比如 NoSql 的多种方案：K-V 存储：在数据结构方面相比关系型数据库具备较大的优势，文档数据库-最大的特点就是 no-schema，可以存储和读取任意数据；列式数据库-在某些场景下能够大大节省 I/O，以及全文搜索引擎-则因为倒排索引机制，在全文检索方面表现出较为显著的优势
而每种场景，也总会有一些解决的通用方法，比如-高可用，可能直接想到的就是冗余。所以当你的知识和经验积累的越来越多的时候，你便更容易完成一个复杂业务的架构设计工作。
要是有了一定的技术经验储备，那么，对于一种业务场景，总是会很快速地确定出一个大致的方案，或者一次性蹦出多个备选方案
但不要轻易满足，每个方案总会有其缺点和局限性。在此基础上，还应该再拓展思路，去寻找一些更优的方案。比如说，对于集群或者异地多活等场景中需要保证数据一致性的情况，除了之前脑子里蹦出来的二次读取的方式、存储系统同步方式以外，通过查阅资料，你会发现，其实还可以采用消息队列方式、回源读取方式以及重新生成等方式。当然这些需要根据具体的业务数据特性来最终确定，或者多个方案配合使用也可以
4、评估和选择备选方案
针对已经确定的备选方案，书中提到了使用备选方案 360 度环评-列出本次方案设计需要关注的架构质量属性，比如：性能、复杂度、成本、可扩展、可用性，然后针对每种复杂度逐一对比多个备选方案，再根据数量对比、加权等方法确定最终方案的方法（包括我见过的几个公司的架构设计模板都是这样的）。但是，仅凭数量肯定是不科学的，加权的话，就需要为每种方案打分了，而打分，又往往会有一定的主观因素，最终方案的选择就变成一个数字游戏了
所以，比较正确的，还是按优先级选择。而这个优先级则是我们在第二步骤中，所排列出来的复杂度优先级
5、详细方案设计
这个步骤，就是将确定的备选方案进行细化，使得备选方案变成一个可以落地的设计方案
在这一步，需要确定关键技术细节。通过分步骤、分阶段、分系统等方式，尽量降低方案复杂度
在平常项目中，到了这一步，我一般做的除了确定关键技术细节之外，还会针对在上一步骤中暂时未满足的某些质量属性，评估多方面的因素，确定出较为简单的追加或者兜底的方案
注意，这里暂时没有满足的质量属性，经过上一步骤的评估，在这里已经不算是关键质量属性了，或者说是优先级很低的质量属性了，因此，可以尽可能地找出一些比较简单的方案来弥补即可，如果实在没有简单可行的方案，那么可以考虑是否可以暂时先不去管
6、技术演进-业务的推动
如果严格按照以上 5 个步骤来进行，那么我们最终确定的方案一定是符合 “合适原则”的。而为了减少方案本身的复杂度，我们还需要把握住一定的限度
比如说，我们追求高性能，评估出当前最大业务要求 TPS 为 1 万，那么就没有必要支持到 100 万
业务量激增的情况确实有可能存在，但概率很小，如果每次做方案都考虑这种小概率事件，我们的方案会出现过度设计，导致投入浪费。考虑这个问题的时候，需要遵循架构设计原则-“演化原则”，避免过度设计、一步到位的想法
按照演化原则的思想，即使真的出现这种情况，那就算是重新做方案，代价也是可以接受的，因为业务如此迅猛发展，钱和人都不是问题
例如，淘宝和微信的发展历程中，有过多次这样大规模重构系统的经历。通常情况下，如果某个质量属性评估和业务发展有关系（例如，性能、硬件成本等），需要评估未来业务发展的规模时，一种简单的方式是将当前的业务规模乘以 2 ~4 即可，如果现在的基数较低，可以乘以 4；如果现在基数较高，可以乘以 2。例如，现在的 TPS 是 1000，则按照 TPS 4000 来设计方案；如果现在 TPS 是 10000，则按照 TPS 20000 来设计方案
所以，方案的确定，不用考虑一步到位，设计时预留出一个 2-4倍 的规模，然后随着业务的增长再做具体的评估调整即可
7、拆分，几乎是万能的
业务层降低复杂性最好的方法就是拆。实现化整为零，分而治之，将整体复杂性分散到多个子业务或子系统里面去
拆，就是将原本大一统的系统，拆分成多个规模小的部分。这些小的部分，往往复杂度就变小了一些。而且正因为分开了，要是需要扩展的话，只修改其中一部分即可，无须整个系统都改，这种方式往往能够减少改动范围，降低改动风险
在生活中，当你发现还有一堆事等着你来做的时候，往往会觉得亚历山大。而当你每天早上在投入到工作中之前，首先列出来你今天需要完成的事项，并按照优先级排列下来，然后再按照优先级一件件去干，干完一个，就标记一下。渐渐地，你就会变得轻松起来。而这个动作，实际上就是拆分
同样地，前面我们提到，当需要对确定的方案进行详细设计的时候，我们通过分步骤、分阶段、分系统等方式，尽量降低方案复杂度，这个步骤就是对业务复杂度的拆分
此外，软件系统架构其实也是在做拆分：
面向流程拆分-将整个业务流程拆分为几个阶段，每个阶段作为一部分-就得到了分层架构
、面向服务拆分-将系统提供的服务拆分，每个服务作为一部分，就得到了SOA 和微服务架构
面向功能拆分-将系统提供的功能拆分，每个功能作为一部分-便得到了微内核架构
三、对于读书本身的感悟
每次读一本技术书，甚至是其他哲学等方面的书时，都会有以下的一些感悟
1、碰撞的惊喜
在书中，往往能够看到在之前其他书籍里或者与之前的见闻的一些碰撞的点。比如说微服务一节，就与之前看过的《微服务架构实战》中作者的很多思想发生了碰撞。想到自己之前接触了一段时间微服务架构，就想着什么系统都要采用微服务来设计，只意识到微服务带来的便利性，却未关注到随之带来的复杂性；
再比如，自己在之前公司中耳濡目染的一些架构方面的技术栈，在这里都有了答复。当时还是一个普通的开发，也没有想过将来真的会从事偏架构方面的工作。总感觉架构是一件很高深的事情，需要智慧超群，并且有很多年的经验的大佬才可以胜任。于是对于听到的 F5 ，虽然知道它是一种硬件 负载均衡设备，脑子里也有着一个疑问：它与我们常用的 nginx 到底有什么区别？但并没有真正去细究过。今天看了书，才知道，原来 CDN-F5-nginx 都是用来做负载均衡的。只是不同的方式有不同的特点，因此就适用于不同的场景。
看完这个图，我恍然大悟，感觉好惊喜。
再比如，之前是银行公司，还经常听到 ESB ，虽然根据大家说的意思，感觉像是银行系统涉及到的所有的系统都需要走这层，类似于中间的转换层。看完书，相当于对这层技术栈的印象加深了很多。它实际上是 SOA 架构（这个名词也常常在书上或者网上见到，大概搜索了一下是“面向服务的架构”，以为就是微服务架构了）中的一部分，类似于微服务中的 网关和注册中心等组件作用，实现了各种系统间的协议转换、数据转换、透明的动态路由等功能
由于当时银行的那个项目，会涉及到多个厂商间的系统调用，而每个厂商的系统又存在很大的区别，有了这个 ESB，对这些系统的接口等信息进行规范化处理，则就比较容易连接起来了。那么这些厂商则只需要进行一些简单的适配就可以了
那么，SOA 架构与微服务到底有什么关系呢？
他们实际上有很多相似点，比如说都会存在很多个服务，也都会有适配层
书中也将两者进行了对比。相对于 SOA 的服务一般指的是一个个系统，微服务本身服务粒度就比较细了，往往指的是把一个系统进行拆分，拆分为多个服务。通信也一般会统一采用统一的 Http Restful 进行。这样复杂度就落在了每个微服务上，而各个微服务本身划分已经足够细，复杂度不会太大，因此开发速度也会比较快，很适合于互联网行业。相对来说，SOA 架构就更适合于企业级的业务了
再回到银行的例子，他们一般情况之所以不采用微服务，采用 SOA 架构，主要原因就在于 各个厂商的系统在协议、数据，甚至字符编码等多个方面都存在差异性，很难统一起来，不可能在短时间内要求他们都统一了，所以就采用 ESB 来对他们进行转换、适配，达到最终的效果
这种碰撞，真的让人拍案叫绝！不仅会加深你之前的一些认知，还能够在你的认知基础上，又不断看到彩虹
2、与实践的共鸣
记得当时在第一次做架构设计，这是一个管理端项目：主要通过调用第三方的接口来实现管理端的功能
在做评审的时候，部门架构师发现整个设计文档主要偏向于架构设计思路方面，对于需求只是描写了个一小段文字。于是他让我首先讲清楚需求
这时，我才发现，由于太重视自己的第一次架构设计，想要尽量把这个架构搞得高大上一点，就查了很多资料，把高可用、高性能、稳定性等等尽可能地放在了这个架构设计里面，对于需求却只了解了个大概
随着后续的几次架构设计，便也深觉他说的很对：对于需求的理解要是不够，根本不能开始做架构，毕竟需求理解准确了，方向才不会错，设计出来的架构才能准确；而在看这本书的时候，看到作者也在强调业务理解的重要性，便立刻感觉到共鸣
架构师还建议将后端拆分为两层-核心后端和业务后端，其中核心后端主要负责第三方接口的封装，而业务后端，则主要负责实现业务的真正逻辑。起初会觉得是不是有点多此一举了，毕竟这个项目本身看起来挺简单的，就主要需要实现其他系统的接口调用，实现相应的资源下发就可以了。所以当时并不觉得这是个好的建议
当我再找他沟通时，他才告诉我，要是分开的话,
首先，架构会清晰，各个层级分别负责不同的功能，分而治之
第二，两者的开发就可以独立开来，由不同的成员进行开发。核心层的开发，主要需要了解其他产品的业务，对于业务需求的理解方面比较高，这个可以交给一个业务能力比较强的人来开发，而业务层，功能则相对比较简单，要是来了新员工，也可以在暂时不了解业务的情况下，轻松上手。
第三，可扩展。这个项目需要做 8 个迭代，需求可能会越来越多，也总是可能发生变化。而核心层相当于一个稳定层，不怎么会发生变化，以后扩展的话，只需要对业务层进行扩展就好啦
第四，可复用。这个稳定层，以后也完全可以被其他项目拿来复用
在之后，也会觉得资深架构师，果然是不一样，目光会更长远，思想也更为先进啊！这一点，也与作者提到的拆分的方式：基于可扩展拆分的思想又不谋而合~
3、熟悉圈扩大，感觉到了快乐
在看这书之前，对于各个模块所讲到的东西，本人基本都是有一定涉猎的，有的是听过，有的是用过，有的则是在架构设计中真正评估过。因此一路看下来，还是比较快的，几乎用了两周左右的零散时间就看完了。而且越看越有兴趣，最后直到看完这本书，合上书，感觉收获比较多
其实我这个人有个嗜好，每次挑选技术书，都是建立在本人对于这类技术有了一定的理论或者实践基础之上的
因为我很喜欢在熟悉的基础上，重新换个角度，或者说更为系统地把这类技术组织起来
在看的过程中，对于已经很熟悉的东西，往往会有一些新的认知，作者换一种思路解读，常常会让我感觉恍然大悟；看这类书籍时，还会与已知的其他知识，连起来，加上自己的理解，实现真正的融会贯通。此外，还往往能够获得一些新的知识，又觉大快人心。于是便想要汲取更多的知识，并感受到越来越多的快乐
4、交流很重要
来到新的公司，碰到了很多优秀的同事。尤其是思维比较敏捷，知识面也比较宽。而上次，我听到主管说了一句话：“我就很喜欢和人交流，因为我觉得交流可以使人进步”。我才突然发现，这些优秀的同事，基本上都有有一个共同点，那就是爱交流！
与人交流，通过语言的沟通，不仅会让我们站在另一个角度看待问题，还往往通过思维的碰撞，拓展我们的思路
读书，就是在与作者交流，与作者产生思维上的碰撞
总得来说，我现在渐渐觉得，交流，会提升你进步的速度！
5、自信来源于自己
之前在自己第一次做架构设计的时候，请教了很多经验丰富的同事，发现他们总是能够针对一个问题有自己独到的理解与思路。而自己就懵懵的 ，似乎啥也不知道，一度怀疑自己的能力是否真正适合做架构设计了。直到后来，我也看了一些书，做了一些架构设计，再与同事交流时，也多少有一些自信了。并且也真正立志要做一名优秀的架构师了~
总结
一个优秀的架构师，会以最简单的模式，来解决业务的复杂度
而看书、交流等方式的持续进行，只会让你距离优秀架构师越来越近！
嗯，就这样。每天学习一点，时间会见证你的强大~
欢迎大家关注们的公众号，一起持续性学习吧~
福利：这本书的电子版，也可以在 青梅主码 公众号，后台回复：架构设计 获取哦~
