自定义博客皮肤VIP专享

*博客头图:

格式为PNG、JPG,宽度*高度大于1920*100像素,不超过2MB,主视觉建议放在右侧,请参照线上博客头图

请上传大于1920*100像素的图片!

博客底图:

图片格式为PNG、JPG,不超过1MB,可上下左右平铺至整个背景

栏目图:

图片格式为PNG、JPG,图片宽度*高度为300*38像素,不超过0.5MB

主标题颜色:

RGB颜色,例如:#AFAFAF

Hover:

RGB颜色,例如:#AFAFAF

副标题颜色:

RGB颜色,例如:#AFAFAF

自定义博客皮肤

-+
  • 博客(11)
  • 收藏
  • 关注

原创 书籍列表

面向模式的软件架构大型网站技术架构:核心原理与案例分析云计算宝典 技术与实践大数据架构商业之路 从业务需求到技术方案敏捷软件开发 原则、模式与实践

2017-01-18 09:51:46 281

原创 系统伸缩性

系统伸缩性,是指在不改变系统软硬件设计,仅仅通过新增服务器的情况下,就能提升系统的处理能力。系统成为大型的,分为2种,一种是开始就设计成大型的,例如12306网站,设计之初就要考虑能并发处理多少请求,要存储多少数据。 另外一种是从小系统慢慢演化成大型系统的,例如google、淘宝,一开始只是几台服务器,然后随着业务的增长系统不断演化。在演化成长型的系统中,最重要的技术手段就是集群。当系统具

2017-01-10 14:54:40 3303 1

原创 系统高可用

高可用网站架构设计的主要目的,就是保证系统出现故障(硬件、软件、网络)时服务仍可用。主要手段就是冗余备份和失效转移,即负载均衡+集群。典型的分层结构是应用层、服务层、数据层。应用层通常为了应对高并发的请求,会通过负载均衡技术将一组服务器组成一个集群对外提供服务。当检测到某个服务器不可用时,  就将此服务器从列表中清除,将请求分发到其它可用服务器,从而使服务保持高可用。服务层也采用负

2017-01-05 16:24:16 628

原创 系统高性能

总的来说,系统的设计是否合理,比局部代码问题,对性能的影响更大。例如,程序设计成频繁读写磁盘中的数据,肯定比先把数据一次性加载到内存中再读写,在合适的时候再写入更新到磁盘的设计,性能要差很多。使用服务器集群、多线程多进程的架构,肯定比使用单服务器、单线程单进程的架构,性能要差。服务端使用异步通信的设计,肯定比同步通信要好。通信消息的设计,消息体的长度设计为变长,肯定要比设计成定长,

2016-12-29 09:53:14 392

原创 模式

模式: 针对特定问题场景的解决方案。分成3个层次: 架构模式、设计模式、语言模式。架构模式: 描绘了系统级结构特征,是软件架构的模板。例如,交互式的软件系统,一般采用的MVC架构模式。 处理数据流的软件系统,采用的 '管道-过滤器' 架构模式。分层架构模式,最常见的是网络通信协议,它被分成了7个层次。设计模式:描绘了子系统、模块之间的关系结构。

2016-12-28 15:57:17 201

原创 接口隔离原则(ISP - Interface Segregation Principle)

某些类的接口,可以分解成多组方法,每组方法都服务于不同的客户。当客户使用这个类时,那么将会导入他们从来不会使用的接口。如果其他客户需要修改这个类时,也将影响到其他无关的客户。我们应该避免这种耦合。方法:1、使用委托分离接口。2、使用多重继承(实现)。

2016-11-04 11:41:45 277

原创 依赖倒置原则(DIP - Dependency Inversion Principle)

a、高层模块不应该依赖于底层模块。它们2者应该都依赖于抽象。b、抽象不应该依赖于细节。细节依赖于抽象。许多传统的软件设计方法,比如结构化分析设计,倾向于设计出高层模块依赖于低层模块、策略依赖于细节的软件结构。对于这种结构,如果低层细节变化,那么上层策略也要跟着变化。明显是不合理的,本应该是高层的策略影响低层的细节实现。如果高层模块都为它需要的服务,声明一

2016-11-04 10:12:52 398

原创 替换原则(LSP - Liskov Substitution Principle)

如何设计最佳的继承层次?  怎样避免类层次结构不符合OCP ?答案就是替换原则(LSP): 子类型必须能够替换调它们的基类型。代码违反LSP原则的明显特征: 使用if 或 if/else 去确定一个对象的类型,从而选择执行对应的行为。更微妙的违规: 正方形(Square)和矩形(Rectangle)的例子。让正方形继承矩形,并重写矩形的setWidth(width=

2016-11-01 09:24:33 1331

原创 开-闭原则(OCP - Open-Closed Principle )

软件实体(函数、类、模板等等)应该是可扩展的、但是不可修改的。可扩展- 增加新的功能。 应对新的功能需求。不可修改- 不修改源码。避免关联源码的修改、重新编译、链接。一个软件实体,例如一个函数,怎样才能做到即增加新的功能,又不修改它的源码呢。答案就是抽象。先看一个不遵守OCP原则的例子:client类调用server类实现某些功能。如果有新的需求,c

2016-10-31 11:15:06 453

原创 单一职责原则(SRP - Single Responsibility Principle)

就一个类而言,应该仅有一个引起它变化的原因。举例说明:违反SRP原则代码:modem接口明显具有两个职责:连接管理和数据通讯;interface Modem{public void dial(string pno);public void hangup();public void send(char c);public void recv

2016-10-28 17:00:36 224

原创 敏捷软件开发

敏捷软件开发它是一个持续的过程。顾名思义,敏捷即快速。此处的快速,意思是指迭代的快速、更改的快速。迭代的快速,比如1周、或2周就提交一个版本。交与客户测试使用,获取反馈。更改的快速,针对不断变化的需求,快速做出反应。需求是不断变化的,我们无法预测会有怎样的需求。一开始就针对一些假想需求做出设计, 或预先使用某些原则、模式, 不仅会增加软件复杂度,更有可能是多

2016-10-28 16:36:27 155

空空如也

空空如也

TA创建的收藏夹 TA关注的收藏夹

TA关注的人

提示
确定要删除当前文章?
取消 删除