转载

『互联网架构』软件架构-软件系统设计（一）

按照正常的互联网玩法，产品经理原型画好进行需求评审，评审完后，需要把需求丢给技术经理，或者技术负责人，进行一整套的概要设计，然后针对概要设计评审，概要评审后进行开发。这次咱们一起说说概要设计的体系结构。了解下套路。

软件系统设计

软件系统设计在很多人眼里就是写文档，写文档是一种负担，其实系统设计头脑风暴，是一种非常开心的事情。所以必须掌握什么是系统的设计。它里面有哪些方法论，如何去做一些系统设计。

我们平常做开发设计吗？

才毕业回郑州那几年，都是一句话就是需求，开发完了河南本地连个测试人员都没有，开发人员说开发完了就开发完了，直接拿给用户进行测试。有的用户直接骂娘，有的用户用的感觉很不爽哭的（工作没做完），有的用户直接摔东西的。聪明的一点的用户都直接联系开发人员帮他来操作。直接测试都没有，用户就是测试人员，说实话7，8年前的告诉用户怎么用，他怎么用。他感觉很神秘，这几年随着互联网产品越来越多，智能手机的普及，大家对软件的要求越来越严格了。很多之前的习惯的同事，现在都没转变过来，真是土，土的掉渣。后来其实也没太关注设计，可能就是之画个图。直到后来跟第三方系统进行交互数据，刚开始草草的设计下，导致之后的2个月都没好过。所以说系统设计是一项非常重要的工作。而不是老铁们经常说的就是写个文档就行了。

拿这键盘直接干。
深思熟虑，考虑到多方的问题，在开始我们的编码。
需求里面是一句话，直接就是干，别墨迹。
做设计的时候，开发人员在考虑？还是技术经理在考虑？

用什么方法做？

瀑布流程（互联网直接忽略）

需求确定的基础上，系统设计的方方面面设计的都很全面，把每个阶段都有非常严格的验证条件，在主流的大型软件的开发方式。

基于原型，快速迭代（互联网常用）

许多创业公司的老板真心喜欢，感觉业务可以进行快速的开发，其实在里面还是有很多的坑在里面的。很少有人基于瀑布来开发。其实快速迭代也变成了很多老板让各位老铁赶项目的理由了。我几个亿的单子，先让用户验证，让用户体验到，大家不能耽误我们伟大的商业模式，就算是这种开发模式也是需要有文档的，对设计不清楚的地方也会有很多，很多的坑在里面，包括后期的性能和扩展也好，如果前期底子没有搭建好的话，后期伤筋动骨。随随便便改一个小功能可能要对程序进行伤筋动骨。但是这个时候老板是不会管你的，测试人员更不会管你，产品也不会管你，他们只知道我们满足业务和需求。

具体设计什么

具体到底需要设计什么？如果系统没有做好一个设计，如果你还是基于所谓的原型，快速迭代敏捷开发以这为借口的话，程序后期越来越大，越来越大的时候真心很伤，根本都不改你的系统，就比如说：银行，社保里面的代码基本是10年前的代码，里面的问题一大堆，但是没有人敢改，这也是设计部合理导致的一个毛病。

体系结构设计

指明了一个系统是什么，它是整个软件中最本质的表现

开发人员看文档的时候，首先就要看体系结构。它是软件系统最本质的东西，主体的形态，人的骨架就是体系结构。如果你设计的体系结构是个大猩猩，后期不管如何进化，如何发展，它始终无法变成一个人，只能是个猩猩。比如盖房子，可能盖高层，可能盖土房，可能盖平房，或者是窑洞，一开始就想盖高层，它需要的材料，地基深度什么都是不一样的。所以体系结构就需要了解软件设计的本质。也可以说架构。

2. 应当设计的很稳定

盖到一半，要换地基是不是很悲催。开发的设计的时候一定要三思而后行。

3. 设计的原则

3.1 适应性

满足用户需求，达成商业的目的。而不是开发人员自己歪歪，高水平的设计人员就是设计出来刚刚满足用户需要的软件，而不是不惜一切代码设计出来一个最先进的软件，没有最好，只有最合适。打造闭环是最好的，对于很多互联网项目，可能不是刚需需求，可能不是成熟的商业模式，如果非要进行闭环，试错的机会都不给，开发的成本老板接受不了，老板无法快速推广到市场里面。开发的功能越多，功能越强大的话，一旦业务发生调整的话，软件不好发生变动。所以要分为很多个阶段。开发和产品经理很多容易犯这个毛病，刚开始就设计都喜欢大而全，精而细。产品经理经常爱说：『别人的系统都有这个功能，你为什么做不了！』，其实可以这么怼过去，给他上一课：『这样的产品设计根本就不能满足现阶段产品设计的适应性！』

3.2 结构稳定性

我们设计的要相对的稳定性，一定确定一定要相对的稳定性，如果经常变动，就相对于房子的地基，你看到那个房子盖好后的地基经常发生变动。如果软件经常发生，太悲剧了。体系结构设计的不稳定，范围不清楚，如果一个系统刚开始是B2C，突然要变成B2B，表结构，系统模块，界面，全部都要发生比较大的改变。整个项目变的很轮乱，需求不停的变动导致系统很混乱。导致开发人员不敢动代码（牵一发动全身），都是复制一份代码。最后维护多份代码。对于高水平的设计师都是有一定经验的，可以预先知道那些需求是基本不变的，那些需求是可变的。

必须导出：可变需求和可变需求。

举个例子：之前项目中针对消息中心的设计，消息中心：对于用户来说会有很多种类的消息。消息除了pc端，移动端也有很多的消息，物流消息，营销消息，通知消息。当时就有一个问题，实际的消息中心，就是接收到各种渠道的消息，然后分发到各个平台（邮件，短信，推送，系统消息信息）。之前没有消息中心，都是业务方自己各自来完成的。为了满足原子性，原子是不可变的，消息中心需要做的就是按照业务方的需求把消息发送出去，发送到对应的渠道，短信。但是消息中心是在业务平台之后设计的，业务平台不可能因为发送消息修改自身的业务代码。在消息中心专门设计了一个监听模块，监听业务方的一个动作，这个模块跟业务平台是紧耦合的，事件监听模块随着业务而变动，消息中心的核心功能不会发生变动的，因为功能很纯粹就是发消息，收消息，推送消息。这就是当时如何保证稳定性的问题。在模块上进行划分。如果之后在需要拆分的话，直接把模块进行拆分。监听模块，按照业务的变更进行变更。

稳定性，就不会被业务需求方赶着走，项目是可控的。天天不用担心老板又有新需求。

3.3 扩展性

软件在扩展新功能的难易程度。扩展性越好，适应变化的能力越强，尤其是敏捷开发，如果扩展能力不强的话，很容易进入一个死胡同里面去。区分可变动和不可变动。软件体量约小，扩展能力越强，船小好调头。为什么项目分阶段，就是为了可扩展。系统的体量肯定受限业务的，越大的项目扩展性越难，所以要进行分布式（应用层，中间业务层，原子服务层），分层（控制层，服务层，数据访问层），越是往下稳定。

合理的业务模块划分，扩展的时候根据模块进行拆分扩展。业务的边界划分。

3.4 是不是所有的系统在设计的时候都要考虑扩展性

一次性项目，只要完成现阶段的功能就可以了，例如两个单独的公司的对接接口，其实很多时候因为可能是一次性的，没必要考虑扩展性，如果考虑可能就变成了过度设计。如果做开放平台的话，肯定要考虑扩展性。

3.5 可复用性

用一次还可以继续在用，工具类，公共的组件。工具类一定设计的纯粹（对使用环境没有假设，少配置零配置，没有依赖）