网站建设多语种自动翻译插件,微网站是免费的吗,企业建站的作用是什么,广州分销商城开发目录
软件架构设计产生的历史背景
软件架构设计的目的
系统复杂度来源
追求高性能
一、单机高性能
二、集群的高性能
追求高可用
一、计算高可用
二、存储高可用
追求可扩展性
一、预测变化
二、应对变化
追求安全、低成本、规模
一、安全
二、低成本
三、规模…目录
软件架构设计产生的历史背景
软件架构设计的目的
系统复杂度来源
追求高性能
一、单机高性能
二、集群的高性能
追求高可用
一、计算高可用
二、存储高可用
追求可扩展性
一、预测变化
二、应对变化
追求安全、低成本、规模
一、安全
二、低成本
三、规模
读书小结 前言 作为后端开发攻城狮学习并掌握一些架构的思想和技能是很有必要的。 《从零开始学架构》的作者李运华资深技术专家。这本书是他从业十多年对架构设计的心得和方法论的总结比较系统化也比较通俗易懂正如他在书中开篇提到的照着做你也能成为架构师。这很接地气也正是吸引我的地方。我打算按照读书的进度记录和总结书中的主要内容再结合我的理解整理成几篇读书笔记定时更新。 软件架构设计产生的历史背景 软件架构概括成一句话系统的组织形式、内部联系和逻辑。 最早在60年代就已经出现“软件架构”这个概念了但真正流行却是从90年代开始的这要从2次软件危机说起 第一次软件危机与结构化程序设计60年代~70年代这次危机的根源在于软件的“逻辑”变得非常复杂这次危机催生了结构化程序设计方法结构化程序方法成为了 70年代软件开发的潮流。 第二次软件危机与面向对象80年代这次危机主要体现在软件的“扩展”变得非常复杂这次危机促进了面向对象的发展80年代开始面向对象成为主流的开发思想。 90年代人们对软件架构的研究发现随着软件系统规模的增加计算相关的算法和数据结构不再构成主要的设计问题当系统由许多部分组成时整个系统的组织也就是所说的“软件架构”导致了一系列新的设计问题。这样很好解释了在一些大规模的软件开发中非常容易面临的问题如系统规模庞大内部耦合严重续修改和扩展困难系统逻辑复杂出问题后很难排查和修复。 70年代的危机主要是逻辑复杂问题结构化编程可以解决这问题创造了“模块”概念80年代的危机主要是软件扩展问题面向对象思想可以解决这问题创造了“对象”90年代的“软件架构”开始流行创造了“组件”概念。我们可以看到“模块”“对象”“组件”本质上都是对达到一定规模的软件进行拆分差别只是在于随着软件的复杂度不断增加拆分的粒度越来越粗拆分的层次越来越高。 软件架构设计的目的 软件架构设计的目的是为了解决软件系统复杂度带来的问题。为什么这么说从前面的两次软件危机可以看到随着系统规模、业务需求的不断增长系统的复杂度功能、性能、扩展、安全等等统称为复杂度会不断上升但上升到一定程度后会导致现有系统难以继续开发维护。引进架构的设计就是在系统开发之初设计可行的架构方案并在迭代过程及早的发现可能出现的危机并针对危机对软件的架构进行调整优化。
系统复杂度来源 既然架构设计的目的是解决系统复杂度带来的问题那就要先了解导致系统复杂度增加的几个主要来源
追求高性能
一、单机高性能 单机的局限性明显主要是通过多进程、多线程的方式提高单机的的吞吐量。
二、集群的高性能 单机的性能有限必须采用机器集群的方式来达到高性能。例如支付宝和微信这种规模的业务系统后台系统的机器数量都是万台级别的。
1、任务分配 任务分配的意思是指每台机器都可以处理完整的业务任务不同的任务分配到不同的机器上执行。分配器可能是硬件网络设备也可能是负载均衡软件例如Nginx、HAProxy等任务分配器需要增加分配算法。一般来说机器数量越多集群整体的性能越强。 2、任务分解 如果业务本身也越来越复杂单纯只通过任务分配的方式来扩展性能收益会越来越低。可以将其拆分为更多的组成部分例如微信的后台架构。 通过这种任务分解的方式能够把原来大一统但复杂的业务系统拆分成小而简单但需要多个系统配合的业务系统。为何通过任务分解就能够提升性能呢
简单的系统更加容易做到高性能 系统的功能越简单影响性能的点就越少就更加容易进行有针对性的优化。而系统很复杂的情况下首先是比较难以找到关键性能点因为需要考虑和验证的点太多其次是即使花费很大力气找到了修改起来也不容易因为可能将 A 关键性能点提升了但却无意中将 B 点的性能降低了整个系统的性能不但没有提升还有可能会下降。
可以针对单个任务进行扩展 当各个逻辑任务分解到独立的子系统后整个系统的性能瓶颈更加容易发现而且发现后只需要针对有瓶颈的子系统进行性能优化或者提升不需要改动整个系统风险会小很多。
3、任务分解的误区 既然将一个大一统的系统分解为多个子系统能够提升性能那是不是划分得越细越好呢其实不然这样做性能不仅不会提升反而还会下降最主要的原因是如果系统拆分得太细为了完成某个业务系统间的调用次数会呈指数级别上升而系统间的调用通道目前都是通过网络传输的方式性能远比系统内的函数调用要低得多。因此任务分解带来的性能收益是有一个度的并不是任务分解越细越好。 追求高可用 和之前高性能是一样的都是通过增加更多机器来达到目的但其实本质上是有根本区别的高性能增加机器目的在于“扩展”处理性能高可用增加机器目的在于“冗余”处理单元。
一、计算高可用 这里的“计算”指的是业务的逻辑处理。计算有一个特点就是无论在哪台机器上进行计算同样的算法和输入数据产出的结果都是一样的所以将计算从一台机器迁移到另外一台机器对业务并没有什么影响。 二、存储高可用 存储高可用的痛点在于多个数据库或缓存服务器之间数据不一定时时刻刻是一致的可能存在某一个时刻数据不一致的问题例如主从数据库的数据同步可能存在网络延迟。 按照“数据 逻辑 业务”这个公式来套的话数据不一致即使逻辑一致最后的业务表现就不一样了。所以存储高可用的难点不在于如何备份数据而在于如何减少或者规避数据不一致对业务造成的影响。 著名的 CAP 定理从理论上论证了存储高可用的复杂度。也就是说存储高可用不可能同时满足“一致性、可用性、分区容错性”最多满足其中两个。后续的读书笔记中详细展开说明吧。
追求可扩展性 设计具备良好可扩展性的系统有两个基本条件正确预测变化、完美封装变化。但要达成这两个条件本身也是一件复杂的事情。
一、预测变化 软件系统在发布后还可以不断地修改和演进这就意味着不断有新的需求需要实现。预测变化的复杂性在于
不能每个设计点都考虑可扩展性。不能完全不考虑可扩展性。所有的预测都存在出错的可能性。
二、应对变化 第一种应对变化的常见方案是将“变化”封装在一个“变化层”将不变的部分封装在一个独立的“稳定层”。
系统需要拆分出变化层和稳定层需要设计变化层和稳定层之间的接口 第二种常见的应对变化的方案是提炼出一个“抽象层”和一个“实现层”。抽象层是稳定的实现层可以根据具体业务需要定制开发当加入新的功能时只需要增加新的实现无须修改抽象层例如设计模式中的策略模式。后续的读书笔记中详细展开说明吧。 追求安全、低成本、规模
一、安全 从技术的角度来讲安全可以分为两类一类是功能上的安全一类是架构上的安全。 功能安全其实就是“防小偷”从实现的角度来看功能安全更多地是和具体的编码相关。 架构安全就是“防强盗”传统的架构安全主要依靠防火墙防火墙最基本的功能就是隔离网络通过将网络划分成不同的区域制定出不同区域之间的访问控制策略来控制不同信任程度区域间传送的数据流。例如DDos攻击防护。
二、低成本 成本可以简单的分为机器硬件的成本、第三方软件的成本、人员开发和维护成本等等
三、规模 软件规模带来复杂度的主要原因就是“量变引起质变”
功能越来越多导致系统复杂度指数级上升数据越来越多系统复杂度发生质变 读书小结 这次读书笔记我主要分享了软件架构的出现的历史背景列举了两次软件危机软件架构设计的目的是为了解决系统复杂度带来的问题以及系统的复杂度的来源等下一次《从零开始学架构》读书笔记我将分享软件架构设计的三个原则、架构设计流程等的读书心得。
