Monday, January 25, 2016

Classic Software Architecture - 经典软件架构模式



经典软件架构模式(一)
针对代码耦合的问题,软件界进行了大量的理论研究和实践,最后发现:系统的架构设计,是改善耦合的最好方式。架构设计的本质,就是:
  1. 划分耦合的单位——也就是划分模块。系统应该划分成什么样的模块,代表了设计者对于系统应对的需求的基本理解。一旦能清晰的划分出模块了,其代码耦合就有了最基本的范围。而模块本身也是提示程序员理解系统的基本单位。

2. 规范耦合的形式——代码耦合的形式有很多种,如直接调用、事件响应、消息队列等等,这些形式提供了代码耦合的不同特征。直接调用的代码在静态阅读的时候非常容易理解,而事件响应则提供了运行时耦合的好处。耦合的形式还有另外一层含义,就是代码耦合的规范:那些模块之间应该直接耦合,哪些不能耦合,是否应该加入中间层次等等。

分层模式

下面我们开始第一个架构模式的介绍,先看一个案例:
这是一个有着复杂功能的多人在线社区,其服务器端是我们需要讨论的重点。这个产品的服务器端必须满足多样的功能:玩家移动到不同的场景中,玩家可以换上不同的服装,可以互相加好友并且聊天,同时还有广播频道的聊天,每个玩家还有自己的资料库和背包,另外还有各种运营活动。

在最初的开发过程中,我们针对每个需要开发的功能,建立了一个模块。这些模块通过单独和客户端、数据库的操作,完成所需功能。如果要开发新功能,就重新写一个这样的模块。这种架构设计在一开始是非常有效的,产品功能被不断的开发出来,模块的数量也在增多,但是也潜藏了一个问题。

这个问题的爆发是随着一个叫做“任务系统”的功能而出现的。因为任务系统本质上是需要很多其他模块的功能提供支持。如需要玩家去某个场景(场景模块),获得某个东西(背包模块),然后添加一个好友(好友模块),或者换上某个服装,说一句话等等……这样的任务功能的实现,被迫要修改很多个模块的代码,因为每个模块都只有最基本的“自由使用”功能的代码,编程接口都仅仅是面向客户端的,而数据结果都是直接SQL到数据库的。这种需要组合的功能请求,以及获得功能的结果状况,都是其接口上没有的。这导致了非常复杂的,持续的代码修改。因为任务的内容可是时常会变化的哦!

在分析了问题之后,我们决定重构整个架构,我们把架构从一字排开的设计,修改成为可以多个层次互相调用的模块。这些模块直接的接口,有面向客户端的,也有面向其他模块的,这样我们就能直接调用那些现成的功能,组合开发出更复杂强大的功能。不管任务系统如何变化,我们都可以不用重写那些已经实现的功能,这让整个系统成为可以应对这种需求变化的关键。
实际上,这样的架构正是一个著名的架构模式——分层模式。
分层模式的规定非常简单而有效:
1. 每个模块都必须属于某个层次,提供给“第N+1层”(上层)服务;同时委派任务给“第N-1层”的模块。
2. 任何一个模块,都不得逆层次调用:属于第N层的模块,不得调用(耦合)第N+1层或以上层次的模块。
3. 任何一个模块,都不得跨层调用:属于第N层的模块,不应该调用第N-2层或更下层的模块。
分层模式是架构中最基本的模式,但是也是我们开发中最被忽视的模式。我们开发中往往没有去定义代码的“层次”,仅仅以“功能”纵向划分模块,没有按实现层次横向切分。
门面模式、策略模式都常常用来实现分层架构。
上文所说的例子,后来改造成了分层模型:
1)重复代码减少了,功能开发更快了——一顶层开发只需要学习下层类库,就可以开始开发;近似功能模块被统一,修BUG覆盖面更好。
2)性能提升代码能更好的覆盖了——集中了通用实现代码,也集中了优化部分
3)可以并行开发,资深人员负责底层,一般人员负责上层
总结一下分层模式:
“模式的模式”——强大同时灵活



★ 方法论:以业务逻辑特征建模 ——使用分层模式,往往需要我们在大脑里对问题领域进行层次抽象,这种抽象最可信赖的原则,就是按照业务逻辑去做。比如现实业务中有一个角色,我们就建立一个角色的模块;如果我们有一个场景,就以此为名建立一个这样的模块……。以业务逻辑建立的模块,本身也会让系统更容易被理解,因为在代码里能找到和现实中一一对应的概念。
★ 设计模式实现:
★ 门面模式 ——我们对于每个模块或者每个层次都会设计一个“门面”来降低耦合的复杂程度。
★ 策略模式——抽象层次会隐藏底层的实现细节,这就是策略模式最基本的设计,我们往往会把上层作为功能接口,下层作为可选的策略来实现。


微核模式
我们来看第二个案例,这是一个多人在线的游戏社区。在这个社区中,除了可以聊天、换衣服之外,还有大量的小型、中型、甚至大型游戏可以玩。这些游戏的内容,都会和整个社区以及角色集合起来,有点像几十个不同的游戏融合成的一个大游戏。


Labels

Review (572) System Design (334) System Design - Review (198) Java (189) Coding (75) Interview-System Design (65) Interview (63) Book Notes (59) Coding - Review (59) to-do (45) Linux (43) Knowledge (39) Interview-Java (35) Knowledge - Review (32) Database (31) Design Patterns (31) Big Data (29) Product Architecture (28) MultiThread (27) Soft Skills (27) Concurrency (26) Cracking Code Interview (26) Miscs (25) Distributed (24) OOD Design (24) Google (23) Career (22) Interview - Review (21) Java - Code (21) Operating System (21) Interview Q&A (20) System Design - Practice (20) Tips (19) Algorithm (17) Company - Facebook (17) Security (17) How to Ace Interview (16) Brain Teaser (14) Linux - Shell (14) Redis (14) Testing (14) Tools (14) Code Quality (13) Search (13) Spark (13) Spring (13) Company - LinkedIn (12) How to (12) Interview-Database (12) Interview-Operating System (12) Solr (12) Architecture Principles (11) Resource (10) Amazon (9) Cache (9) Git (9) Interview - MultiThread (9) Scalability (9) Trouble Shooting (9) Web Dev (9) Architecture Model (8) Better Programmer (8) Cassandra (8) Company - Uber (8) Java67 (8) Math (8) OO Design principles (8) SOLID (8) Design (7) Interview Corner (7) JVM (7) Java Basics (7) Kafka (7) Mac (7) Machine Learning (7) NoSQL (7) C++ (6) Chrome (6) File System (6) Highscalability (6) How to Better (6) Network (6) Restful (6) CareerCup (5) Code Review (5) Hash (5) How to Interview (5) JDK Source Code (5) JavaScript (5) Leetcode (5) Must Known (5) Python (5)

Popular Posts