首席架构师汪洋坐镇，欢迎大伙提问啊：软件架构连载讨论之一：正确认识软件架构

yanyangtian4502

回复 11# snow888


    说的到点子上了。这样说吧，

首先，让我们来看看架构的一个定义：
软件架构是对系统的高层视角，或者是对系统的抽象。它关注某些对完成这个系统有着最大帮助的方面，例如：可用性、稳定性，以及灵活性。同时，架构对如何达到这些目的给出了指导和约束。

如果要用最简单的方式来理解上面的定义，可以这样说：软件架构就是软件系统的一张蓝图。

下面我们用一个比较浅显的类比来说明这个“蓝图”的含义。

相信大家对冶金行业中的“浇筑”或多或少有一些了解。浇筑就是把液体材料倒在一个有着特定形状的沙模中，然后等液体冷却之后得到想要的产品或特定形状材料的过程。在这个过程中，盛放液体的沙模引导着液体慢慢成形，最后得到我们预想的结果。

其中，有一点我们要注意就是，沙模的特性（比如形状和大小）和倒入其中的液体是没有任何联系的，换句话说：沙模和液体是完全分离的，但是沙模又必须和液体在一起才能生产出所要的产品。

架构就好比上面例子中的沙模，软件项目就好比用于浇筑的液体。正如浇筑一样，架构引导着项目，最后得到我们想要的结果。同时，我们也可以得出：软件的架构和实现这个系统的代码是没有很严格的关系的，这也就是我们常说的架构是平台无关的。架构确保开发的过程在一定的限制或规则下进行。
沙模没有浇筑液体的存在，基本就没有任何作用；架构也是立足项目的特定需求来设计的！

yanyangtian4502

正如之前所说，架构和设计是两个不同的概念，它们也出现在不同的阶段。当软件系统的架构确定之后，设计就开始了。

架构与系统的业务需求往往是紧密联系的，理论上来说，架构不是很关注系统最后搭建在哪个技术平台上（例如：或是J2EE上，或是.NET上），但实际上，很多时候我们在考虑架构创建的同时，也考虑了系统将要运行的技术平台。

设计是与系统的实现相关的。设计将架构所关注的那些高层抽象的需求与具体的技术实现联系起来，从而考虑如何实现系统所需要的稳定性、安全性。更加细节的如，考虑采用哪种模式等。在设计阶段，还要决定在以后开发的过程中应采用哪种实现方法论进行开发（例如，是TDD，还是DDD或是BDD等）。

yanyangtian4502

采用一张图来说明架构和设计的相互关系，如图所示：
如图所示，业务需求是系统架构的决定性因素，软件设计和开发在架构确定之后开始进行，而开发过程又是在设计的基础上进行的。

yanyangtian4502

架构师在创建架构的时候，首先必须理解系统的高层需求，然后做出相应的设计决定。例如，如果需要为一个SNS站点增加邮件群发系统，架构师在创建邮件系统的架构之前首先会关注以下几点：
        邮件系统将会运行在哪里？部署托管的环境是什么？托管环境有什么技术限制？
        发送的邮件是否需要数据保护？
        每天或每小时内发送多少封邮件？
        系统给用户发送邮件的频率是多大？
        邮件是否允许带附件？附件的大小、格式是否有限制？
        这个邮件系统是否需要扩展或重用（例如，其他站点或公司是否也会采用这个邮件系统）？
然后架构师在这些问题及一些其他的问题的基础上给出每个问题的答案，这样就可以根据答案画出系统架构的草图了。从而可以得出：架构的关注点不是在功能的细节上面，而是在于系统所要达到的目标及与这些目标相关的需求上。

yanyangtian4502

当架构师了解这些关注点之后，接下来就要考虑折中的办法。
例如，对信息的加密会使得安全性提高，但是也会损耗一定的性能；利用配置文件的方式确实可以增加系统的灵活性，但是会降低可用性；在使用配置文件的时候，是采用标准的XML还是自己定义格式；系统如何进行部署才能兼顾性能和最低的成本，等等。

架构师还需要理解这些关注点和它们之间的约束关系，然后和利益相关人商量、协作，为这些关注点排列优先级，最后在给出的架构中体现这些关注点。为了达到各方面的平衡，架构师常常要和不同的部门及人进行沟通，然后采用权衡策略，所以架构师不是只懂得技术就可以了的。

liuliu8031

高手

yanyangtian4502

这个话题还有很多地方可以深入进去，朋友们可以就我和一些论坛里面朋友的帖子发表意见，也可以发表自己的看法！

snow888

采用一张图来说明架构和设计的相互关系，如图所示：
如图所示，业务需求是系统架构的决定性因素，软件设计 ...
yanyangtian4502 发表于 2011-10-13 09:23

    嗯，就是这张图的关系，其实空搬书本的谈论架构，就是俺们俩说了，也未必能让所有的人都清楚架构究竟是咋回事。

我们用一个简单的软件开发例子来说说：假设我们需要为国际连锁沃尔玛开发一套系统，当然，由于我们仅仅是为了讲清楚啥子是架构，啥子是架构设计，这个系统我们力求简单，仅考虑如下几个方面的需求。

业务运营系统、物流调度系统、会计核算系统、报表分析系统这四个小得部分，我们不考虑实现完整的一个沃尔玛的系统。仅从以上四个方面来考虑。

首先，业务运营系统为了简化起见，我们把网络购物系统从业务运营系统中分开，这里的业务运营系统仅包含超市的运营系统，很显然，由于超市收费系统是高效率的运转的实时系统，通过很多的系统模拟与测试，这样的模型以C/S架构更为稳定与合理，同时从输入的角度上来说，这样的架构模型，输入效率更高。输入界面采用字符控制台界面更符合操作习惯（我们很难想象，在收费的时候，手不停的在键盘、读码器、鼠标间切换，输入效率会很高）

那么我们再来看看，物流调度系统，主要是及时掌握各超市的商品销售信息，及时进行商品采购和在各超市之间的调度，这样的系统至少需要考虑城域网的范围，出于从成本考虑，可采用 Inter 网，这样由于地域范围较大，且为了适应不同的客户端环境（有 WinXP、Win Vista、Win7 甚至可能有 ubuntu 等不同环境），很显然，为减少开发成本，同时为提高系统的安全性和适用性，我们可采用 B/S 架构，采用 java + js 语言开进行开发，同时从系统安全性考虑，我们可选择中间层隔离并加装防火墙设备等，Brow 层不直接与数据库交互，后台采用交易响应机制，C 语言编写，同时考虑到物流调度，因此需要引入工作流（有关工作流如何与本系统集成，此处暂不做展开，我们主要是讲清楚哪些是架构，什么架构设计）。

会计核算系统，同样是一个数据输入量不是太大的系统，主要用于做会计收支方面的账务处理（营运系统有一部分的会计数据产生，可直接转入），这方面如果可能，可采用现成的会计核软件，通过其提供的 API 公共接口接入数据，也可以自行开发这样一个高度整合的会计核算系统，这方面采用 C/S 或 B/S 都可以。

最后是报表分析，由于营运系统需要报表分析，各分销商需要报表分析，总部也需要报表分析，且多数情况下需要进行信息的交流与融通，与物流调度系统一样，这部分同样需要采用 B/S 方式，其大致组成方式也与物流调度相仿。

以上这些模型在软件项目中就是架构，而形成这些组成模型，并将其形成书面的资料的过程，就是架构设计了。

snow888

当然，上述四个系统需要整合在一个平台内，这同样有一个系统安全性与中间层隔离的问题。

同样，由于越到上层，数据量越大，因此在服务器端，可考虑专用的系统如 HP-UX ，和专用的小型机等。而各分销商和超市，由于数据量较小，可采用 Linux 和 PC Server 服务器等支撑，那么这不同的系统间的数据传输与交互方式，也是架构的一个组成部分，而思考这个部分的过程，就是架构设计了。