什么是软件系统架构设计

在软件中架构模式主要有两种，一种是c/s模式，一种是b/s模式，这里一起探讨下b/s架构怎么设计，希望对大家有帮助，请帮忙点赞

第一步

b/s模式是浏览器--服务器的模式，这中模式比c/s 客户端-服务端的模式好，有点较多：

b/s模式可以随时更新，用户不用频繁的升级客户端

第二步

架构b/s模式，主要是服务端的架设，一般情况浏览量比较小的时候只需要一台服务器

第三步

如果网页需要与记录客户的一些信息，比如资料、订单之类，需要涉及到数据库，需要在服务器端增减数据库

第四步

当客户较多时，需要做负载均衡，需要F5、或者ngxin：

第五步

当数据库压力比较大的时候，需要建立数据库的集群：

设计模式是架构的手段（之一）。

具体一点说，设计模式可以在某些情况帮助架构软件的静态结构。

而架构的范围要大一些，更高层一些，考虑的更多的是非常重要的全局性的design decision。一般好的（静态）架构可以尽量使变化发生在局部（模块内）而不影响整个系统。架构上的变化往往成本会非常高。

而且设计模式只有一些是适用于架构的，还有一些只是用于具体的类设计的，剩下的一些则只是克服编程语言的限制而已。

打个不恰当的比方，有点像挡拆和战术的关系。

在合适的情况下用好挡拆可以很好的执行战术，

但战术不只有挡拆，

而且有的战术不需要挡拆，

最重要的是盲目的用挡拆有时候反而会起反作用。

面对客户哔哔时，我们用需求分析架构。

面对整个软件或系统时，我们谈论架构分析。

面对软件模块设计时，我们使用设计模式。

面对模块实现时，我们应用特定编程语言的特性。

软件架构 ：一般场景下拥有设计的选择权

设计模式 ：选择后特定场景下的最佳实践

软件架构是软件的一种搭建形式，往往规定了软件的模块组成，通信接口（含通信数据结构），组件模型，集成框架等等。往往规定了具体的细节。

设计模式是一种软件的实现方法，是一种抽象的方法论，是为了更好的实现软件而归纳出来的有效方法。

实现一种软件架构，不同组成部分可能用到不同的设计模式，某一部分也可能可以采用不同的设计模式实现。

架构设计是一个大家耳熟能详的词，基本都烂大街了。

可是，到底什么是架构设计呢？估计很多人就回答不上来了。

下面就来详细聊聊什么是架构设计，以及对架构设计的一些基本认识。

软件架构设计指的是：对一个软件系统进行的架构定义、文档编写、维护和改进、并验证实现的一系列活动，架构设计的产物就是一个系统的架构。

架构设计实际上是一个过程，围绕着软件系统，对它的架构，进行定义、文档编写、维护和改进、并验证实现等，把这一系列活动组合起来，就是我们所说的架构设计。

架构设计的产物，也就是结果，就是架构，这也是架构和架构设计的关系。

架构设计是一门科学，这个已经是业界共识。但是作为一门科学来讲，它一定要有它自己的基础理论，基础方法，也会有一些实现的方法论。

架构设计作为一门科学来说，还很不成熟。目前架构设计的基础理论还不是很完善，方法论上，更是百花齐放，大家都还处于一个探索的阶段。

从科学上来讲，架构设计主要关注架构设计过程当中的：技术、流程、资源、方法；以及如何去完善并改进架构。

刚讲到架构设计这门科学还很不成熟，再加上技术领域更新很快，新技术、新思想、新方法 层出不穷。

我们总会面对很多新兴的、没有先例的系统，可能会应用新的框架、新的技术、新的解决方案来实现系统。

因此，做架构设计的时候，是需要一定的创造力的。当然，艺术细胞缺乏的人员也不用太担心，架构设计上还是有很多是有章可循的，多半是在已有的架构体系上去做一些微调，微创新，并不是完全从零开始。

架构设计不是一蹴而就的，通常也是由粗到精，刚开始，可能只有一个粗略的架构设计，然后不断迭代和演化，逐步推进，去完善和细化，这样的过程。

这个可能有些人不太理解，认为说，软功过程里面，不是有专门的概要设计、详细设计的时间吗？架构设计不就是在这些设计阶段去完成的吗？做完设计了，把文档发下去，不就没事了吗？

有些公司也是这么干的，实际上这是有问题的。

架构设计会跨越软工的完整流程，对于一些大型的或者是重要的项目，可能立项期间，架构师就要参与，做一些粗略的架构规划，有两个基本的原因：

1：能不能做得了这件事

2：按照粗略的架构规划做下去，大致的成本会有多大

立项的时候，就要去考虑你的成本，风险和投资收益。

也就是说，立项的时候，架构师可能就需要参与，那就更不用说需求阶段、设计阶段了，架构师是肯定要参与的，前面讲需求分析的时候已经讲过了，这里就不多啰嗦。

到了编码阶段，有些人可能认为架构师是不参与的，这是不对的。架构师需要参与，只是参与的少一些，主要是一些重点、难点的地方，或者是公共基础功能，由架构师来实现。

另外在编码阶段，架构师还有一个重要的任务，就是确保开发人员按照架构设计去实现，不要乱做。这就需要两个基本的方式，一个是架构师要把架构设计的成果，跟开发人员讲解清楚，并不断沟通；另外一个就是要不断检查，Review，以确保架构设计的落地实现不出大的偏差。

后面的测试、部署、运维等阶段，架构师要做一些技术咨询，或者是技术指导的工作。架构设计里面，本来就包含部署架构的设计，因此，架构师也会参与这些阶段，只是参与的少一些。

总之，架构设计需要关注所有利益相关者的要求，参与系统设计实现的所有人员，也都是系统的利益相关者，自然而然的，架构设计就需要贯穿软工的整个流程了。

一个系统，要关注的方方面面是很多的，利益相关者也很多，大家关注点各有不同。

这就意味着，在做架构设计的时候，需要不断去做决策，在众多关注点中去寻求平衡，所以有人说，做架构设计，就是一种玩平衡的艺术。

比如：从技术上讲，A+B的方式是性能最高的；但是从成本上来看，A+C是最合适的。可能最后综合权衡后，B+C是各方都能接受的方案。

这种需要考虑的平衡很多，比如：技术和成本的平衡；方案适用性年限的平衡，是满足1-3年就够了，还是要考虑8-10年；技术方案和当前开发人员技能的平衡；性能和成本的平衡等等，非常多。

架构设计是一个过程，需要在这个过程中，不断去考虑各利益相关者的要求，并不断折中平衡，因此架构设计的产物，也就是架构，自然就是各方利益相关者的共识了。

要做出好的架构设计，经验是不可或缺的，不会每次都是从零开始。

比如以前做过类似的系统；或者是学习到的一些好的架构模式，设计模式，一些现成的组件；或者是一些开源的框架等等的，这些我们都可以看成是可重用的资源。

我们做架构设计的时候，需要不断去积累这样子的可重用资源，形成自己的工具箱。这样当我们在做一个系统的架构设计的时候，就有了很多备用的工具或手段。

有了这些经验和资源的积累，会使得新系统的架构设计变得更容易。

软件架构是指在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构，它包括该系统的各个组件，组件的外部可见属性及组件之间的相互关系。组件的外部可见属性是指其他组件对该组件所做的假设。

软件架构设计就是从宏观上说明一套软件系统的组成与特性。

软件架构设计是一系列有层次的决策，比如：功能与展现的决策；技术架构的决策；自主研发还是合作；商业软件还是开源软件。

业务需求层出不穷；软件系统越来越复杂；参与的人越来越多；共性和特殊性的问题越来越多；技术发展日异月新。

分类描述1解决方案架构师与客户探讨业务需求，将业务、市场，与技术、产品结合起来，为客户提供解决他们需求的方案。2系统架构师也称应用架构师。最终确认和评估系统需求，并将业务转换为技术，为研发人员制订核心框架与技术规范为研发工作澄清技术细节并扫清技术障碍。3平台架构师这里的平台其实包括两个平台，一个是系统平台，也就是负责搭建多个系统整合的系统应用平台；另外一个其实是基础平台，是专门负责搭建基础技术平台；两者其实区别蛮大，也经常容易被从业人员混乱。举个简单例子，金蝶有平台架构师一职，但是金蝶BOSS应用和金蝶中间件两者招聘的对象和技术要求是截然不同的。4业务架构师业务架构其实已经开始脱离技术层面了，但是它要求架构师有跨越多系统的大局观，去整合和组织不同系统的技术平台与交互模式。其实这个职位的未来也就是CIO了。5网络架构师过去，我们可能听的最多的是网络工程师。不错，一个优秀的网络架构师必须有足够的网络技术基底，并且它的关注点也是系统的基础架构。比如说如果搭建并优化集群环境，如果构建基于云计算的系统应用与部署等等。它对于像淘宝、腾讯这样的互联网公司是极其重要的。6移动架构师移动互联网的迅猛发展横向和纵向都细分出了很多新的职责和岗位，移动架构师的职责和作用日益重要，既要整体和全局考虑整个前后端的软件系统架构，又要重点深入移动客户端的架构设计的方方面面，既要有跨平台思维，又要拿捏好原生和混合开发的尺度，另外移动应用的特点，导致移动架构师必须要比传统系统架构师更加注重非功能性的质量属性。7前端架构师这也是移动互联网的迅猛发展而细分出来的新的职责和岗位，这里的前端特指网站开发中的前端，主要考虑前端呈现层的设计（HTML/CSS/JS/AJAX/RIA/?），跨浏览器设计等等。

软件架构设计的几个步骤 1、分析需求和理解业务模型（或领域建模），并选定关键Use case。 软件的需求，可以分为从用户视角和开发人员视角来看，从用户的角度看，又可以分为功能性和非功能性需求，我们必须从不同的视角和级别去全面的认识需求并分析需求，理解业务模型。实践表明，常常被我们忽视的非功能性需求常常会导致整个项目失败。 理解业务需求最好的方式莫过于进行领域建模，领域建模与需求分析往往是交替穿叉进行的，领域建模主要有以下三个方面的作用： ◆探索复杂问题，弄清领域知识。Martin Fowler曾经说过，他采用面向对象方法最大的好处就是它有助于解决更为复杂的问题。领域建模本身作为辅助思维的工具，帮助我们将注意力始终保持在最为重要的业务概念及其关系上，使我们能够不断深入地，系统的对需求进行分析和认识。领域建模往往是一个从模糊到清晰，从零散到系统的过程。 ◆决定功能范围，影响可扩展性。任何模型都是对现实世界某种程序的抽象，这种抽象就会忽略某一些东西，例如忽略对象的属性和对象间的关系，而这些忽略往往都是带有一定的目的性的，这种忽略就决定了功能的范围。模型揭示了各种功能背后的结构，如果说定义功能相当于“拍照片”的话，那么领域建模就相当于“做透视”，更加关注问题领域的内在结构，相当于对问题领域进行了一定的抽象，良好的领域模型不仅能很好的支持现有的功能，而且还可以在一定程度上支持未来可能出现的新需求，体现良好的可扩展性。 ◆提供交流基础，促进有效沟通。领域建模通常会使用UML图作为呈现的方式，这样为我们的沟通提供了方便。当然，有时候文字在描述某些特定领域的问题时可能更适合，可以灵活运用。 在我们公司的实际软件开发流程中，往往领域建模缺少这一环节，这可能是在以后的工作中需要进一步提高之处。 虽然我们总是期望架构设计师能全面掌握需求，但由于时间和精力的限制，摆在我们面前的现实就是架构设计师没有时间对所有需求进行深入分析，所以我们的策略就是“把好钢用在刀刃上”，即把大部分时间和精力花在对决定架构最重要的关键需求上。在选择关键需求时要注意：高优先级的需求往往是从用户的角度来看的，可能并不是真正的关键需求。在《RUP实践者指南》一书中向我们讲述了如何确定关键功能需求？A.作为应用程序的核心或实现了系统的主要接口的功能，B.必须被实现的功能，即如果这些功能不被实现，则开发出来的软件就失去了价值，C.覆盖了系统架构的一些方面，但没有被其他重要的Use case覆盖到的功能。 2、分别从各个视角来考虑软件架构的方方面面。 软件的架构设计必须考虑到各方面，根据前期工作确立的领域模型，关键需求，系统约束等进行设计，必须从系统用户，开发人员，系统管理员，部署管理员，数据管理员等人员的角度去分析并解决问题。比如说，如果我们的运行架构采用Cluster方式时，就必须小心Cache和Session等的使用；如果我们的业务逻辑要求我们要操作多个数据库时，就要考虑采用支持二阶段事务提交的方式。 只有将这些方方面面的问题都考虑到了，这样的架构设计才是完整的。至于每一个视图中，我们应该设计到什么细节这一问题，实际上与整个项目的过程定义有关。例如，如果我们有专门安排数据库概要设计的活动，那我们在架构设计的过程中就可以只需要关注更高层次的数据库特性及数据库之间的关系，而每一张表的数据字典可以在后续的相关活动中进行设计，但如果没有这样的活动，那我们就要细化到每一张表的每一个栏位，以及表之间的关系。 3、解决技术面的重点问题和难题 在软件架构设计的过程中，我们往往会需要攻克一些技术面的重点问题和难题，这完全是一项极其需要扎实的理论知识和丰富的实践经验支撑的工作。例如，我们如何提高整个系统的性能？如何能很好的导出极其复杂的“中国式报表”（一般比西方国家产出的报表要复杂很多，而且很多开源的BI类的框架并不能完全解决问题）？ 当遇到确实是很困难的问题，可以去百度一下或Google一下，也可以去请教公司的资深技术人员或专家，或者召开小范围的技术专题讨论会议，采用脑力激荡的方法试着找找答案，这样才能提高工作的效率。 4、召开架构设计评审会议进行同行评审。 架构设计评审是极其重要的一环，我曾将其形容为“七种武器”中的离别钩，就是因为在会议上，同行们可能会提很多问题或意见，而且很多意见很尖锐，所以一定要虚心接受，并做好记录，正所谓“良药苦口利于病，忠言逆耳利于行”。 在评审会议之前，我们要完成很多准备工作，最好是能准备一份简明扼要的电子简报，把最重要的问题列出来，这样在进行评审会议时，就不会漫无目的，在会议前就将这些资料发给与会人员，请他们抽空先了解一下，在会议进行时，要学会控制会议的进度，提高会议的效率。 5、针对关键Use case在设计的架构上实现功能来验证架构。 对于架构设计的验证也是一项十分重要的工作，其验证技术有很多种，在我们公司通常会采用Sample的形式，即XP中所说的迭代0，RUP中所说的切片。这样做的好处是既可以从实际的产品角度出发来有效的验证架构是否满足要求，又可以比抛弃型原型验证技术节省成本。 这个Sample绝不是我们在解决架构设计中的问题时拿来做实验的一些代码的拼凑，而是完整的实现某一关键Use case的符合架构设计和一系列规范的可交付的代码及相关文档。同时，这个Sample可以作为你在给大家讲解或培训架构时的教材，也可以作为开发人员使用此架构进行开发的蓝本，甚至是只需要复制粘贴，加上简单的修改即可。 6、交付给客户Review。 这一环节，在很多公司可能并不存在，因为他们的软件架构并不一定需要客户Review，但像我们这种做服务的公司，最重要的就是客尊，落实到软件架构设计这一活动，就是让客户理解并接受你的架构设计方案，同时，客户也会起到帮你验证架构的作用。通常，我们的架构得到客户的认可后，便可进入大规模的开发。 在交付给客户Review时，通常

作为一名多次做过报告的架构设计师，我给出一些我的看法。

如果可以使用图形的话，给你两个方案：第一是使用专业图形，如UML图，顶层架构图，时序图（好吧，这个包含于UML）等。非常适合专业人士之间交流。第二是使用XMIND（或者类似软件），站在产品角度，通过XMIND来描述产品各个模块功能及联系。

如果不可以使用图形的话，也给你两个方案：第一是你的受众（就是看你报告的人）的专业素养较高，那么你可通过将系统进行业务的拆分（横+纵），如Web服务端的接入层，应用层，服务层，数据层等方式进行分层汇报。第二是你的受众的专业素养较低，那你需要从多个维度来对你的系统架构进行描述，并做出一些生动的例子辅证。

当然，最好的方式就是图形加一定的文字描述。如果时间充裕的话，你还可以建立对应动态图片，来说明。

（纯手打，如果帮助到你，希望点个赞。）

软件架构作为一个概念，体现在技术和业务两个方面。

从技术角度来说：软件架构随着技术的革新不断地更新其内容，软件架构建立于当前技术和一些基本原则的基础之上。

先说一些基本原则：

分层原则：分层是为了降低软件深度复杂性而使用的关键思想，就像社会有了阶级一样，软件有了层次结构。

模块化原则：模块化是化解软件广度复杂的必然手段，模块化的目的就是让软件分工。

接口实现分离原则随着软件模块化的不断深入改进，面向接口编程而不是面向实现编程可以让复杂度日趋增高的软件降低模块之间的耦合度，从而让各模块更轻松改进。从这个原则出发，软件也从微观进行了细致的规范化。

还有两个比较小但很重要的原则：

细节隐藏原则很显然把复杂问题简化，把难看的细节隐去，能让软件结构更清晰。其实这个原则使用很普遍，java/c++语言中的封装原则以及设计模式中的Facade(外观)模式就很能体现这个原则的精神。

依赖倒置原则随着软件结构的进一步发展,层与层之间、模块与模块之间的依赖逐渐加深，而层、模块的动态可插拔要求不端增大。依赖倒置原则可看视为接口实现分离原则的深化，根据此原则的精神，软件进入了工具时代。这个原则有点类似于知名的好莱坞法则：Don't call us, we'll call you。

以上这些原则奠定了我们的软件架构的价值指标。但软件架构毕竟是建立在当前技术之上的。而每一代技术都有架构模式。过去的不再说了，让我们就来看一下当前流行的技术，以及当前我们能采用的架构。

因为面向对象是当前最流行开发技术，且设计模式的大量使用使面向对象的走向成熟，而数据库是当前最有效的存储结构、web界面是当前最流行的用户接口，所以当前最典型的三层次架构就架构在以上几项技术的基础之上，用数据库作存储层、用面向对象来实现业务层、用web来作为用户接口层。我们从三层次架构谈起：

因为面向对象技术和数据库技术不适配，所以在标准三层次架构的基础上，我们增加了数据持久层，来管理O-R双向映射，但目前一直没有最理想的实现技术。cmp和entity bean技术因为其实现复杂，功能前景有限，已接近被淘汰的边缘。JDO及hibernate作为o-r映射的后期之秀，尤其是hibernate，功能相当完备。推荐作为持久层的首选

在业务层，因为当前业务日趋负载，且变动频繁，所以我们必须有足够敏捷的技术来保证我们的适应变化的能力，在标准j2ee系统中session bean负责业务处理，且有不错的性能表现，但采用ejb系统对业务架构模式改变太大，且其复杂而昂贵，业务代码移植性差。而spring 作为一个bean配置的轻量级架构，漂亮的IOC模式实现，对业务架构影响小，所以推荐作为中间层业务框架。

在用户结构层,虽然servlet/jsp/jstl/javaBean 能够实现MVC架构，但终究过于粗糙。struts对MVC架构的实现就比较完美，Taperstry也极好地实现MVC架构，且采用基于事件的方式，非常诱人，惜其不够成熟，我们仍旧推荐struts作为用户接口层基础架构。

因为业务层是三层次架构中最有决定意义的，所以让我们回到业务层细致地分析一下，在复杂的业务我们常常需要以下基础服务的一种或几种：事务一致 性服务acid(tool:jta/jts)、并发加锁服务concurrent&&lock、池化管理服务cache、访问控制服务(tool:jaas)、流程控制服务workflow、动态实现服务IOC，串行化消息服务(tool:jms)、负载平衡服务blance等。如果我们不采用重量级应用服务器(如weblogic,websphere,jboss等)及重量级组件(EJB)，我们必须自己实现其中一些服务。虽然我们大 多情况下，不需要所有这些服务，但实现起来却非易事。幸运的是我们有大量的开源实现代码，但采用开源代码却常常是件不轻松的事。

随着xml作为结构化信息传输和存储地位日渐重要,一些xml文档操作工具(DOM,Digester,SAX等)的使用愈发重要，而随着 xml schema的java binding工具(jaxb,xmlbean等)工具的成熟，采用xml schema来设计xml文档格式，然后采用java binding来生成java bean 会成为主要编程模式,而这又进一步使数据中心向xml转移，使在中小数据量上,愈发倾向于以xquery为查询语言的xml数据库。现还有一个趋势， microsoft,ibm等纷纷大量开发中间软件如(microsoft office之infopath)，可以直接从xml schema 生成录入页面等非常实用的功能。还有web service 的广泛应用，都将对软件的架构有非常重大的影响。至于面向服务架构(SOA)前景如何，三层次架构什么时候走入历史，现还很难定论。

aop的发展也会对软件架构有很深的影响，但在面向对象架构里，无论aspectJ还是jboss-aop抑是aspectWerks、 nanning都有其自身的严重问题：维护性很差，所以说它将很难走远。也许作为一个很好的思想，它将在web service里大展身手。

rdf,owl作为w3c语义模型的标志性的语言，也很难想象能在当前业务架构发挥太大影响。但如果真如它所声称那样，广泛地改变着信息的结构。那么对软件架构也会有深远影响。