应用软件系统架构设计的“七种武器”

作者：张明星 出处： dev2dev.bea.com.cn
 
    对于软件架构这一概念，有太多的版本，目前在业界由大师级人物或组织提出的对这一概念的阐述就超过十种以上，我个人比较赞同RUP(Rational Unified Process)中对软件架构的定义，即软件架构包含了关于以下问题的重要决策：

• 软件系统的组织；
• 选择组成系统的结构元素和它们之间的接口，以及当这些元素相互协作时所体现的行为；
• 如何组合这些元素，使它们逐渐合成为更大的子系统；
• 用于指导这个系统组织的架构风格：这些元素以及它们的接口，协作和组合。

    本文我们并不是要探讨软件架构的定义，只是想基于上面这种定义来谈谈在软件系统架构设计的过程中，我们会常常用到的一些“武器”。

长生剑：UML(UML2)

    UML(Unified Modeling Language)这一建模语言已经成了软件设计人员的必备工具，几年前就曾有过“苦干年之后，不通UML者无法染指软件开发”的言论，虽然从目前来看，UML的应用还并未达到如此程度，但使用UML最大的好处在我看来就是减少了沟通的成本，让我们把一些想法能够很清晰直观的表达出来，在设计的过程中，使用得较多的是用例图，类图，组件图，部署图和时序图。当下，各种设计和建模工具对UML都有良好的支持，UML本身也是一门不断发展的语言，现在UML2已经成为主流。UML本身也极为简单，对于初学者来说可能有些概念比较难懂，可以结合实际的程序来理解，这样会事半功倍，但我认为也不会太高深，熟练使用就达到了应有的境界。

    剑谱：

    UML官方网站　http://www.uml.org/

    《UML基础、案例与应用(第3版)》，此书作为UML入门较为适合，书中也以详实案例来教会我们怎么使用UML。

孔雀翎：Office

    架构设计的成果就是两项重要的产出物，一是框架代码，二是架构设计文档。在架构设计文档中，除了包括一些UML图之外，还有一些UML无法表示的图表，采用Office来制作和撰写这份文档再合适不过，最常用的就是Word，Excel和Visio。

    掌握这门“武器”不难，可利用这门武器把各类文档写好就难了，除了专业能力，良好的文字表达能力也是十分重要的，一个成熟的架构设计师在我看来应该也能写得一手好文章，最基本的要求就是能够准确的表达你想要表达的意思。
秘籍：

    《Word排版艺术》，在大陆十分有名的台湾IT作家候捷的作品(之所以这样说是我曾经跟我们公司在台北的同事聊起过此人，几乎没人知道此人)，此书一度借着他的名气卖得很火，因为他出书很多，在这方面也有很多优秀的经验，值得借鉴。

碧玉刀：IDE(IBM RSA或Borland Together)

    通常我们所说的IDE(Integration Development Environment)是指集成开发环境，在这里我借用这个词，指的是集成设计环境。随着软件业的发展和进步，支持一整套开发流程的全系列软件越来越多，越来越好，这其中以IBM Rational Software Delivery Platform最为突出，RSA(Rational Software Architect)就是其中一项，作为建模工具，对领域模型的设计，UML及SOA(Service-Oriented Architecture)等都有较好的支持，同时可以与RMC(Rational Method Composer)结合，充分发挥MDA(Model Driven Architecture)的思想，把RUP流程发挥到极至。

    不过发现RSA也有不好用和不听话的时候，最新的RSA V7.0里面的反向工程就不是很好用，反向过来后很多关系消失了。
Together作为老牌儿的建模工具，也有着先进的思想和设计，其核心包括四个方面：只维护单一模型库(Live Source技术)；符合最小的元模型；扰乱改变模型；支持持续的质量测量。同时，对正反向工程也有良好的支援。也正是因为其有自己的思想和独特的一套，Borland公司也才会将其并入旗下。

    刀谱：

    IBM RSA之《教学指导》，Eclipse平台都有这东东，大家自己去发掘吧，通俗易懂。

    IBM RSA相关的Redbook(http://www.redbooks.ibm.com/)，大名鼎鼎的红宝书，相信入行不久就一定会知道的(其实在大学的时候就人有看什么GRE的红宝书，TOEFL的红宝书，估计红宝书一词来源于此)

    《Getting Started Guide for Borland Together 2006 for Eclipse》官方教你怎么玩转Together，权威信不用质疑，英文版，但看起来并不难懂。

多情环：架构设计类经典书籍

    架构设计类好书不多，但也不是没有，我也没有认真读过几本，但觉得有那么两本还值得推荐：《Pattern Of Enterprise Application Architecture》，Martin Flower的经典之作，几乎是架构设计人员的必读之书，详细论述了企业应用各layers上的模式和设计思想；《Large-Scale Software Architecture》，告诉你什么样的人才是架构师，然后以构件为粒度深入探讨架构的方方面面，同时用UML呈现，也是一份UML在架构设计中应用的最佳实践；《J2EE Core Pattern》，设计Java平台应用系统的经典参考书，对GOF(Gong Of Four)的设计模式在Java中的应用和扩展进行了深入的讨论，看看你的设计中可以运用其中的哪些核心模式。

    秘籍：

    有一套适合自己的学习知识的方法，对于IT行业的人来说，要看的书籍和资料远远超过其他行业，面对如此繁杂的知识，要有自己的方法学会去整理，要做到看必有收获，否则不如去温习古龙或是金老爷子的小说。我常常喜欢用Mind Manager等软件把读书笔记和心得记录下来，也常常回过头来看看这些笔记，以前喜欢手抄，信奉什么好记心不如乱笔头，但后来发现有些落后，不能与时俱进，方式肯定会被淘汰，人自然也会被踢出局。

霸王枪:Internet/Intranet

    当今时代，离开网络这条枪对于IT从业人员来说寸步难行，大多公司目前都还没有自己完善的Intranet，公司知识库的资料与Internet的资源相比可谓是小巫见大巫，但千万不要忽视了公司通过SEPG(Software Engineering Process Group)或相似职能部门积累起来的知识，这些东西往往关注于行业，领域或适合于你所在公司的实际状况，从这个方面考虑的话，其力量超越Internet，是很好的模板。常常我们会遇到自己不能解决的问题，这个时候就需要去网上百度一下；在架构设计文档中，我总喜欢弄个术语表，而对于有些术语的解释，你会发现百度原来也是一本好辞典。

    枪谱：

    百度，谷歌

    利用搜索引擎，可以快速的获得自己需要的资料，大幅提高效率，也不至于让你淹死在浩如烟海的信息海洋中。

    之所以将百度写在前面，是因为我的个人习惯，常常在搜索的时候会优先考虑用百度，在百度搜不到的情况下才去谷歌，百度出来的大都是中文资料，对于母语是中文的人来说，会提高我们的阅读速度和理解效率，命中率较高，较好的分词技术，值得推荐。谷歌当然不错，相信不用多说。

离别钩：评审

    邀请你公司的架构设计同行，资深技术专家，公司领导，或行业中的其他专家，还有你的PM(Project Manager)，充分利用团队的力量，对于你所做的架构设计的初稿进行评审，在评审前先把重点部分，特别是你想跟大家一起讨论更好解决方式的部分整理成简单的演示文稿(PPT)发给大家，同时把详细资料也发给大家，请大家在有空的时候提前了解。在评审会议时，要先向与会人员介绍一下项目背景，需求，千万不要忘了非功能性需求(包括性能，安全，可扩展性等方面)，然后再从重点的议题开始与大家一起讨论，这样可提高效率。

    秘籍：

    虚心听取各方面意见。评审时大家会提出各种各样的问题，有时候可能会提出各种让你很生气的问题，这个时候一定要克制住自己的情绪，虚心的听取他们提出的建议，对各种问题进行解释，让他们真正明白你的意思，同时也从他们那里获取有用的建议。

拳头：激情

    这也是与人最密切相关的一样武器，拳头是你身体密不可分的一部分，激情也是你思想密不可分的一部分，要想把架构设计做好，有做好一件事的激情是必不可少的，你要对新知识，新技术充满好奇心，要有创新精神，在前人的基础上，结合自己的所学去进行一些小的创新，其实人类的进步也就是靠这样的一次次的小创新，以最大程度的确保架构的稳定性和可扩展性，同时也尽可能的提高程序开发的效率。

    秘籍：

    确定自己的发展方向就是做一个技术专家。如果你对自己的职业规划有一些想法，不妨可以考虑一下这个方向，国外的很多大师级的人物因技术牛而成就了卓越的事业，国内目前也有向这个方向发展的趋势。

    我认为做一个技术专家与向管理方向发展并不冲突，技术专家也可以是管理行家，软件行业的很多人都是“技术优则管理”，否则你在管理者的位置上却不懂得基本的技术，在各方面都会遇到绊脚石，也没有人真正的服你。

    正如古龙所说，“武器是死的，人却是活的”。“武器”是否能令你觉得神奇刺激，主要还得看使用它的是什么人，虽然架构设计不是人人都可以做的，但我相信这几种武器通过大家自己的努力一定可以掌握。

zhuweisky

    经过这几年的积累，在系统架构方面逐渐积累了一些自己的经验，到今天有必要对这些经验作个小结。在我的架构思维中，主要可以归类为三种架构模型：3/N层架构、“框架＋插件”架构、地域分布式架构。

一．三种架构模型

1．3/N层架构
    这是经典的多层架构模型，对于稍微复杂一点或特别复杂的系统，不使用分层架构是很难想象的。下图是经典的3层架构：

    如今，凡是个程序员都能侃侃而谈3/N层架构，这确实是解决系统复杂性的一种主流模式，但是，只要采用了3/N层架构是不是就一定能解决系统的复杂性了？不一定，关键在于你在你的系统中如何实作你的3/N层结构。
    在采用了3/N层架构后，我们还是要解决以下非常重要的问题：系统的可扩展性（能从容地应对变化）、系统的可维护性（因为系统并不是使用一次就被抛弃）、方便部署（在需求变化时，方便部署新的业务功能）、还有等等其它系统质量属性。然而系统的可扩展性和可维护性是大多数软件系统必须解决的重中之重，这是由于当前需求复杂多变的软件环境决定的。就像实现功能需求是最基本的，采用3/N层架构也只是万里长征的第一步。
    我采用“框架＋插件”架构来解决与系统的可扩展性、可维护性和部署相关的难题。

2. “框架＋插件”架构
    经典的3/N层架构是对系统进行“纵向”分层，而“框架＋插件”架构对系统进行“横向”分解。3/N层架构和“框架＋插件”架构处于一个平等的位置，它们没有任何依赖关系。
 

    但是我经常将它们结合在一起使用，我们的系统在经过3/N层架构的纵向分层和“框架＋插件”架构的横向分层后，可以被看作一个“网格”结构，其中的某些网格可以看作是“扩展点”，我们可以在这些扩展点处挂接“插件”。也就是说我们可以在3/N层架构的每一层都挂接适当的插件来完成该层的一些功能。如：
 

    插件最主要的特点是可以实现“热插拔”，也就是说可以在不停止服务的情况下，动态加载/移除/更新插件。所以，采用插件技术可以实现以下功能：
    （1）在UI层，我们可以在运行时，替换掉某些用户界面、或加载与新的业务相关的用户界面。在业务逻辑层，我们可以在运行时加载、替换或者删除某项业务服务。在数据访问层，通过使用插件技术我们可以动态地添加对新的数据库类型（如MySQL）的支持。
   插件的“热插拔”功能使得我们的系统有非常好的可扩展性。
    （2）如果我们需要升级系统，很多情况下，只要升级我们的插件（比如业务插件）就可以了，我们可以做到在服务运行的时候进行插件的自动升级。
    （3）要想将系统做成“框架＋插件”的结构，要求我们需要在系统的各层进行“松耦合”设计，只有松耦合的组件才可以被做成“插件”。
  
    在3/N层架构中融合“框架＋插件”架构，最难的是对业务逻辑层的松耦合处理，这需要我们细致分析业务需求之间的关联，将耦合度紧密的业务封装在一个组件中，如此得到的相互独立的业务组件便可以有机会成为插件。这个过程可能需要不断的重构、设计的重构。
    我们知道，相比于那些紧密耦合的组件，松耦合的组件更加清晰明确、更加容易维护。另外，在该架构模型中引入了AOP框架进行Aspect焦点的集中编程（比如处理日志记录、权限管理等方面），使得Aspect代码不会掺杂在正常的业务逻辑代码中，使得代码的的清晰性、可维护性进一步增强。
    从上述介绍可以看出，采用3/N层架构和“框架＋插件”架构相结合，我们可以增强系统的可扩展性、可维护性和简单部署升级的能力。

3. 地域分布式架构
    我无意中发明了“地域分布式架构”这个词，呵呵，不知道意思是否表达得准确。地域分布式架构主要针对类似LBS（基于位置的服务）的需要进行地域分布的应用。      地域分布式架构基于上述的3/N层架构和“框架＋插件”架构，它们的关系如下：
 

    现在我对地域分布式架构作个简单的介绍。假设我们需要为全国的各个大城市提供我们的业务功能服务，假设每个城市的客户量很大，而且每个城市访问的数据可能是不一样的（如每个城市的地图数据）、访问的功能也不尽相同（如有的城市提供天气查询服务，而另一些城市不提供）。客户除了跟我们的系统请求服务之外，可能还想通过我们的系统与他的好朋友进行即时通信，而它们好朋友可能与他在同一个城市，也可能位于另外一个城市。
    好了，我们看地域分布式架构是如何解决类似上述的需求的。
    首先，地域分布式架构将用户管理和业务功能服务分开，分别由应用服务器（AS）和功能服务器（FS）负责，然后将它们部署到不同的节点上。AS和FS都采用了3/N层架构和“框架＋插件”架构相结合的架构，比如，FS通过功能插件提供功能服务。

    比如，对于武汉这个地域，我们部署了一台AS和一台FS，客户端通过连接到AS进行服务请求。假设有一天，我们在武汉的客户急剧增加，这是压力最大的是FS，因为所有的业务计算都是在FS上完成的。
    这时，地域分布式架构将允许我们在不停止任何服务的情况下，动态的添加FS服务器，新添加的FS服务器会自动注册到AS。
 
    AS可以监控每个FS的负载（如CPU消耗、内存消耗），再有客户端请求到来时，AS会将请求交给负载最低的FS处理，这就实现了FS的负载均衡。
    如果Client A需要与Client B进行即时通信，那么这些通信消息将通过AS中转。
    上面看到的是我们的系统在武汉的部署，而在其他城市部署情况也一样。

    在这种情况下，AS和AS之间是相互独立的，但是经常会发生AS之间需要相互通信的情况，比如：Client A需要与Client E进行即时通信，或者Client A需要请求上海地区独有的服务，等等。
    地域分布式架构使用跨区域的应用服务器（IRAS）来解决AS之间的通信问题。所有AS在启动的时候，将自动向IRAS注册。

    如果，我们想在长沙市也提供我们的服务，那么我们只需要在长沙部署我们的AS和FS，这样就可以融入到上图表示的整个地域分布式架构中。
    关于地域分布式架构，就简单的介绍这么多，更多的内容，读者可以自己去分析挖掘。

二．对架构模型的支持

    如果没有自己的一套工具对上述的架构模型作支持，那么你可能会认为我是在这里胡扯、夸夸其谈。在这几年的开发中，我积累了几套框架和类库用于对上述架构模型提供支持。
    （1）DataRabbit 提供了基于关系和基于ORM（轻量）的数据访问，通过插件的方式来支持新的数据库类型。

    （2）ESFramework 解决了分布式系统（如上述的地域分布式架构）之间的底层通信（直接基于TCP和UDP）。

    （3）AddinsFramework 为“框架＋插件”架构模型提供支持。

    （4）ESAspect 通过Proxy方式实现的AOP框架，对方面编程提供支持。

    （5）EsfDRArchitecture 为地域分布式架构模型提供支持。比如支持，FS的动态添加/移除；FS的负载均衡；AS与FS、AS与IRAS之间的通信；跨区域的服务请求等等。可以参见http://zhuweisky.cnblogs.com/archive/2006/03/15/350408.html了解更多。