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

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

2. 应当设计的很稳定

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

3. 设计的原则

3.1 适应性

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

3.2 结构稳定性

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

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

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

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

3.3 扩展性

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

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

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

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

3.5 可复用性

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