一文总结软件架构设计常用概念、原则与思想
导读
本文一文总结软件架构设计常用概念、原则与思想,包括面向对象六大原则,DID原则,ACID、CAP、BASE理论,中间层思想,缓存思想等。
面向对象设计六大原则
一 单一职责原则(SRP):
定义是就一个类而言,应该仅有一个引起他变化的原因。也就是说一个类应该只负责一件事情;
二 开闭原则(OCP):
定义是软件中的对象(类,模块,函数等)应该对于扩展是开放的,但是对于修改是关闭的;当需求发生改变的时候,我们需要对代码进行修改,这个时候我们应该尽量去扩展原来的代码,而不是去修改原来的代码,因为这样可能会引起更多的问题;
三 里氏替换原则(LSP):
所有引用基类的地方必须能够透明地使用其子类的对象;子类可以去扩展父类的功能,但是不能改变父类原有的功能,它包含以下几层意思: 1.子类可以实现父类的抽象方法,但是不能覆盖父类的非抽象方法; 2.子类可以增加自己独有的方法; 3.当子类的方法重载父类的方法时候,方法的形参要比父类的方法的输入参数更加宽松; 4.当子类的方法实现父类的抽象方法时,方法的返回值要比父类更严格;
四 依赖倒置原则(DIP):
高层模块不应该依赖底层模块,两个都应该依赖抽象;抽象不应该依赖细节,细节应该依赖抽象;定义有点绕,说白了,就是要针对接口编程,而不是对实现编程;(抽象指的是接口或者抽象类,两者皆不能实例化;而细节就是实现类,也就是实现了接口或者继承了抽象类的类,它是可以被实例化的;高层模块指的是调用端,底层模块是具体的实现类,在java中,依赖倒置原则是指模块间的依赖是通过抽象来发生的,实现类之间不发生直接的依赖关系,其依赖关系是通过接口来实现的,这就是通俗的面向接口编程)
五 接口隔离原则(ISP):
客户端不应该依赖他不需要的接口;
六 迪米特原则(LOD):
一个对象应该对其他对象保持最小的了解;
Robert C Martin在21世纪早期将单一职责,开闭原则,里氏替换,接口隔离和依赖倒置5个原则定义为SOLID原则。
DID原则
Design(D)设计20倍的容量;Implement(I)实施3倍的容量;Deploy(D)部署1.5倍的容量。 DID为产品扩展提供了经济,有效,及时的方法。
中间层思想
计算机系统软件体系结构采用一种层的结构,有人说过一句名言:
Any problem in computer science can be solved by another layer of indirection. (计算机科学领域的任何问题都可以通过增加一个间接的中间层来解决。)
这句话几乎概括了计算机系统软件体系结构的设计要点,整个体系结构从上到下都是按照严格的层次结构设计的,不仅是计算机系统软件整个体系是这样的,体系里面的每个组件比如OS本身,很多应用程序、软件系统甚至很多硬件结构都是按照这种层次的结构组织和设计的。 纵观计算机体系,中间层思想无处不在,比如
- MVC三层架构
- 四层/七层网络模型
- 添加缓存层提升系统性能
- ……
缓存思想
世界是相似的,在商业的世界中,有一句经典语录叫 “现金为王”。在互联网乃至整个软件技术世界中,与之对应的一个说法就是 “缓存为王”。 纵观整个系统,缓存无处不在。
CPU缓存
由于CPU的运算速度要比内存读写速度快很多,CPU总有等待数据的时候,而高速缓存则解决了CPU运算速度与内存读写速度不匹配的矛盾。当CPU调用数据时,先从缓存中调用,从而加快读取速度。而且,CPU是有多级缓存的。
浏览器缓存
前端页面缓存有两层含义,一个是页面自身对某些页面元素或全部元素进行缓存,另一层意思是服务端将静态页面或动态页面的元素进行缓存,然后给客户端使用。这里的页面缓存指的是页面自身的缓存或者离线应用缓存。 HTML5 支持了离线缓存和本地存储,使用这种特性可以很方便的创建页面应用。
网络中的缓存
- CDN缓存
- 反向代理缓存
服务端缓存
- 内存级缓存
- 分布式缓存
数据库缓存
拿mysql来说。mysql使用查询缓冲机制。将select语句和结果存在缓冲区。下次遇到相同select就直接从缓冲区拿数据。
ACID(酸)
ACID,指数据库事务正确执行的四个基本要素的缩写。数据库必须同时满足ACID支持强一致性,ACID指如下内容:
A:原子性(Atomicity)
原子性是指事务是一个不可分割的工作单位,事务中的操作要么都发生,要么都不发生。
C:一致性(Consistency)
事务前后数据的完整性必须保持一致。
I:隔离性(Isolation)
事务的隔离性是多个用户并发访问数据库时,数据库为每一个用户开启的事务,不能被其他事务的操作数据所干扰,多个并发事务之间要相互隔离。
D:持久性(Durability)
持久性是指一个事务一旦被提交,它对数据库中数据的改变就是永久性的,接下来即使数据库发生故障也不应该对其有任何影响
CAP(帽子原理)
CAP原则又称CAP定理,指的是在一个分布式系统中,CAP三个要素最多只能同时实现两点,不可能三者兼顾。 CAP分别是指
C:一致性(Consistency)
所有节点在同一时间的数据完全一致,这里的一致性指的是强一致性
A:可用性(Availability)
对于一个可用性的分布式系统,每一个非故障的节点必须对每一个请求作出响应。通常我们用几个9
来描述可用性,比如5个9的可用性意思为可用水平是99.999%,即全年停机时间不超过 (1-0.99999)36524*60 = 5.256 min。
P:分区容错性(Partition tolerance)
分区容错性指分布式系统在遇到某节点或网络分区故障的时候,仍然能够对外提供满足一致性和可用性的服务。比如现在的分布式系统中有某一个或者几个机器宕掉了,其他剩下的机器还能够正常运转满足系统需求。
BASE(碱)
eBay的架构师Dan Pritchett源于对大规模分布式系统的实践总结,在ACM上发表文章提出BASE理论,BASE理论是对CAP理论的延伸,核心思想是即使无法做到强一致性(Strong Consistency,CAP的一致性就是强一致性),但应用可以采用适合的方式达到最终一致性(Eventual Consitency)。
BA:基本可用(Basically Available)
基本可用是指分布式系统在出现故障的时候,允许损失部分可用性,即保证核心可用。 电商大促时,为了应对访问量激增,部分用户可能会被引导到降级页面,服务层也可能只提供降级服务。这就是损失部分可用性的体现。
S:软状态(Soft state)
软状态是指允许系统存在中间状态,而该中间状态不会影响系统整体可用性。分布式存储中一般一份数据至少会有三个副本,允许不同节点间副本同步的延时就是软状态的体现。mysql replication的异步复制也是一种体现。
E:最终一致(Eventually consistent)
最终一致性是指系统中的所有数据副本经过一定时间后,最终能够达到一致的状态。弱一致性和强一致性相反,最终一致性是弱一致性的一种特殊情况。
酸碱平衡理论
ACID是传统数据库常用的设计理念,追求强一致性模型。BASE支持的是大型分布式系统,提出通过牺牲强一致性获得高可用性。 ACID和BASE代表了两种截然相反的设计哲学,基于根据ACID与BASE提出了酸碱平衡理论
,即在不同场景下,分别使用ACID与BASE解决分布式一致性问题。
感谢阅读,如有启发,点个赞吧!这将是我写作的最强动力!
同时小编在此免费分享50种设计模式与六大原则,把它做成了一个文档,同时也整理出一些对应的视频资料,需要的朋友们进
java群找管理员免费领取一下!点击链接加入群聊【Java/架构技术交流三群】:https://jq.qq.com/?_wv=1027&k=5XSzo6L 感谢信任!