《从零开始学架构》

版本	作者	参与者	完成日期	备注
YanlzFramework_Zero_V01_1.0	严立钻		2019.03.03
扫描二维码关注公众号，回复： 8701397 查看本文章

##《从零开始学架构》发布说明：

++++“从零开始学架构”：是对“架构”的一个了解，架构设计是技术人员成长和晋升过程中必须掌握的技能；架构的了解包括：什么是架构、架构设计的目的、架构设计原则、架构设计流程、架构设计模式和技巧、互联网公司技术演进等内容；架构适用领域包括：后端架构设计、前端架构设计、客户端架构设计、测试平台架构设计、测试平台架构设计、运维平台架构设计等；

++++“从零开始学架构”：定位在一个科普类知识，让大家熟悉架构！

##《从零开始学架构》目录

#第一篇：架构的基本概念

#第二篇：高性能架构模式

#第三篇：高可用架构模式

#第四篇：可扩展架构模式

#第五篇：立钻哥哥带您架构实战

#推广：【XR游戏开发QQ群：784477094】

#第一篇：架构的基本概念

#第一篇：架构的基本概念

++++立钻哥哥：软件架构指软件系统的顶层结构；因为架构很重要，所以要做架构设计；为了高性能、高可用、可扩展，所以要做架构设计；架构设计的主要目的是为了解决复杂度带来的问题；主要的软件系统复杂度有高性能、高可用、可扩展、低成本、安全、规模等几种；

++++A.1、架构基础

++++A.2、架构设计原则

++++A.3、架构设计流程

++++A.4、立钻哥哥对架构概念的拓展

##A.1、架构基础

++A.1、架构基础

++++立钻哥哥：软件架构指软件系统的顶层结构；架构设计的主要目的是为了解决软件系统复杂度带来的问题；

++++A.1.1、钻哥百科

++++A.1.2、架构相关基础

++++A.1.3、

###A.1.1、钻哥百科

++A.1.1、钻哥百科

++++立钻哥哥：软件架构（Software Architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计；软件架构是一个系统的草图；软件架构描述的对象是直接构成系统的抽象组件；

++++软件架构设计要达到的目标：可靠性（Reliable）；安全性（Secure）；可扩展性（Scalable）；可定制化（Customizable）；可伸缩性（Extensible）；可维护性（Maintainable）；客户体验（Customer Experience）；市场时机（Time to Market）等；

++++架构师按职责通常分为：企业架构师；信息架构师；数据库架构师；业务架构师；系统架构师等；

###A.1.2、架构相关基础

++A.1.2、架构相关基础

++++立钻哥哥：Linux有架构，MySQL有架构，JVM也有架构，使用Java开发、MySQL存储、跑在Linux上的业务系统也有架构；学习业界开源系统（MySQL、Hadoop等）的架构，研究大公司的架构实现（例如：微信架构、淘宝架构等）；

++++微信有架构，微信的登录系统也有架构，微信的支付系统也有架构；

++系统与子系统

++++立钻哥哥：系统泛指由一群有关联的个体组成，根据某种实时运作，能完成个别元件不能单独完成的工作的群体；它的意思是“总体”“整体”或“联盟”；

++++[关联]：系统是由一群有关联的个体组成的，没有关联的个体堆在一起不能成为一个系统；

++++[规则]：系统内的个体需要按照指定的规则运作，而不是单个个体各自为政；

++++[能力]：系统能力与个体能力有本质的差别，系统能力不是个体能力之和，而是产生了新的能力；

++++[子系统]：子系统也是由一群有关联的个体所组成的系统，多半是更大系统中的一部分；

++模块与组件

++++立钻哥哥：从逻辑的角度来拆分后得到的单元就是“模块”，从物理的角度来拆分系统得到的单元就是“组件”；划分模块的主要目的是职责分离，划分组件的主要目的是单元复用；

++++[模块]：软件模块（Module）是一套一致且相互有紧密关联的软件组织，它包含程序和数据结构两部分；现代软件开发往往利用模块作为合成的单位；模块的接口表达了由该模块提供的功能和调用它时所需的元素；模块是可能分开被编写的单位，这使得它们可再用，并允许开发人员同时协作、编写及研究不同的模块；

++++[组件]：软件组件定义为自包含的、可编程的、可重用的、与语言无关的软件单元，软件组件可以很容易地被用于组装应用程序；

++框架与架构

++++立钻哥哥：框架和架构比较相似的概念，且两者有较强的关联关系，这两个概念并不是区分得很清楚；

++++[框架]：软件框架（Software Framework）通常指的是为了实现某个业界标准或完成特定基本任务的软件组件规范，也指为了实现某个软件组件规范时，提供规范所要求之基础功能的软件产品；（框架是组件规范；框架提供基础功能的产品；）

++++[架构]：软件架构（Software Architecture）是指软件系统的“基础结构”，创造这些基础结构的准则，以及对这些结构的描述；（软件架构指软件系统的顶层结构；）

++架构设计的目的

++++立钻哥哥：架构设计的主要目的是为了解决复杂度带来的问题；主要的软件复杂度有高性能、高可用、可扩展、低成本、安全、规模等几种；

++++[高性能]：软件系统中高性能带来的复杂度主要体现在两方面，一方面是单台计算机内部为了高性能带来的复杂度；另一方面是多台计算机集群为了高性能带来的复杂度；

++++[高可用]：系统的高可用方案五花八门，但万变不离其宗，本质上是通过“冗余”来实现高可用，就是一台机器不够就用两台；（通过冗余增加了可用性，但同时也带来了复杂性；）

++++[可扩展性]：设计具备良好可扩展性的系统，有两个基本条件：正确预测变化、完美封装变化；（要达成这两个条件，本身也是一件复杂的事情）

++++[低成本]：低成本给架构设计带来的主要复杂度体现在：往往只有“创新”才能达到低成本目标；

++++[安全]：安全本身是一个庞大而又复杂的技术领域，并且一旦出问题，对业务和企业形象影响非常大；

++++[规模]：规模带来复杂度的主要原因就是“量变引起质变”，当数量超过一定的阀值后，复杂度会发生质的变化；

##A.2、架构设计原则

++A.2、架构设计原则

++++立钻哥哥：成为架构师是每个程序员的梦想，但并不意味着把编程做好就能够自然而然地成为一个架构师，这里有“不确定性”；

++++A.2.1、合适原则

++++A.2.2、简单原则

++++A.2.3、演化原则

###A.2.1、合适原则

++A.2.1、合适原则（合适优于业界领先）

++++立钻哥哥：优秀的架构都是在企业当前人力、条件、业务等各种约束下设计出来的，能够合理地将资源整合在一起并发挥出最大功效，并且能够快速落地；

++++[将军难打无兵之仗]：没有那么多人，却想干那么多活；

++++[罗马不是一天建成的]：没有那么多积累，却想一步登天；

++++[冰山下面才是关键]：没有那么卓越的业务场景，却幻想灵光一闪成为天才；

###A.2.2、简单原则

++A.2.2、简单原则（简单优于复杂）

++++立钻哥哥：无论结构的复杂性，还是逻辑的复杂性，都会存在各种问题，所以架构设计时如果简单的方案和复杂的方案都可以满足要求，一定要选择简单的方案；（Kiss原则：Keep It Simple, Stupid!）

++++[结构的复杂性]：结构复杂的系统几乎毫无例外地具备两个特点：组成复杂系统的组件数量更多，同时这些组件之间的关系也更加复杂；（组件越多，就越有可能其中某个组件出现故障，从而导致系统故障；某个组件改动，会影响关联的所有组件，这些被影响的组件同样会继续递归影响更多的组件；定义一个复杂系统中的问题总是比简单系统更加困难；）

++++[逻辑复杂性]：逻辑复杂的组件一个典型的特征就是单个组件承担了太多的功能；逻辑复杂几乎会导致软件工程的每个环节都有问题；（功能复杂的组件另一个典型特性就是采用了复杂的算法，复杂算法导致的问题主要是难以理解，进而导致难以实现，难以修改，并且出了问题难以快速解决；）

###A.2.3、演化原则

++A.2.3、演化原则（演化优于一步到位）

++++立钻哥哥：软件架构描述的是一个软件系统的结构，包括各个模块，以及这些模块的关系；对于软件来说，变化是主题，软件架构需要根据业务发展不断变化；

++++软件架构设计：首先，设计出来的架构要满足当时的业务需要；其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善；最后，当业务发生变化时，架构要扩展、重构，甚至重写，代码也许会重写，但有价值的经验、教训、逻辑、设计等却可以在新架构中延续；

++++架构师在进行架构设计时需要时刻提醒自己不要贪大求全，或者盲目照搬大公司的做法，而是应该认真分析当前业务的特点，明确业务面临的主要问题，设计合理的架构，快速落地以满足业务需要，然后在运行过程中不断完善架构，不断随着业务演化架构；

##A.3、架构设计流程

##A.3、架构设计流程

++++立钻哥哥：架构师都是技术人员的终极方向，是技术金字塔的顶端；架构设计是有套路的，按照套路去做，即使没有丰富的架构设计经验，也能做出基本可行的架构；

++++A.3.1、识别复杂度

++++A.3.2、设计备选方案

++++A.3.3、评估和选择备选方案

++++A.3.4、详细方案设计

###A.3.1、识别复杂度

++A.3.1、识别复杂度

++++立钻哥哥：架构设计的本质目的是为了解决软件系统的复杂性，所以在我们设计架构时，首先就要分析系统的复杂性；

++++架构的复杂度主要来源于“高性能”“高可用”“可扩展”等几个方面，但架构师在具体判断复杂性的时候，不能生搬硬套，认为任何时候都从这三个方面进行复杂度分析就可以了；

###A.3.2、设计备选方案

++A.3.2、设计备选方案

++++立钻哥哥：架构设计是一个技术活，而技术往往又与创新联系在一起；只有当某种方式完全无法满足需求的时候，才会考虑进行方案的创新，而事实上方案的创新绝大部分情况下也都是基于已有的成熟技术；

++++通过360度环评的方式来评估备选方案；

++++新技术都是在现有技术的基础上发展起来的，现有技术又来源于先前的技术；将技术进行功能性分组，可以大大简化设计过程，这是技术“模块化”的首要原因；技术的“组合”和“递归”特征，将彻底改变我们对技术本质的认识；

++[NoSQL]：Key-Value的存储和数据库的索引其实是类似的，Memecache只是把数据库的索引独立出来做成了一个缓存系统；

++[Hadoop大文件存储方案]：基础其实是[集群方案+数据复制]方案；

++[Docker虚拟化]：基础是LXC（Linux Containers, LXC）；

++[LevelDB]：LevelDB的文件存储结构是Skip List；

++++[错误1：设计最优秀的方案]：根据架构设计原则中“简单原则”的要求，挑选合适自己业务、团队、技术能力的方案才是好方案；否则要么浪费大量资源开发了无用的系统（设计了50000TPS的系统，实际TPS只有500），要么根本无法实现（10个人的团队要开发现在的整个淘宝系统）；

++++[错误2：只做一个方案]：架构师需要设计多个备选方案，需要考虑：备选方案的数量以3~5个为最佳；备选方案的差异要比较明显；备选方案的技术不要只局限于已经熟悉的技术；