架构设计这种东西

架构设计这种东西，只能从实例里面学。用抽象的总结描述架构设计的方法，懂的人听了没用，不懂的人听了不知道在说什么。但举真实的例子很难。因为能公开的例子，要不太旧，没有什么意义；要不太新，基本上都会有保密问题。

最近跟论文的时候看了一本书，本周刚看完，感觉完全能解决我前面说的问题，推荐给有兴趣的各位：

这完全是一份5G网络构架设计说明书，如果你需要一个参考，考虑你的架构设计怎么做，把他作为模板来学习就行了。

当然，如果你只能学习形式，不能形而上地考虑逻辑，非要形而下地学习人家有那些章节和标题，那当我没说过。

下面做一个阅读赏析。为了讨论的方便，我们把上面这本书，或者架构设计说明书，叫做《5G》。

在讨论前，先说说我的背景，我工作早期（二十多年前吧）做过几个无线系统的平台支持，比如GSM BSC/MSC的主控板的驱动，话务统计，3G PDCP的OS

平台提供等等，最近几年偶尔也会解决一两个相关产品的操作系统层的问题，此外，我大部分时间都是在做其他领域的平台软件。所以充其量是对其中的名词术语和要解决的问题“有所耳闻”，对于无线产品设计的细节基本上是个外行。所以我这里并不是讨论5G系统应该如何设计，我也没有能力评判那个设计做得好不好。我是要通过这个设计考虑的逻辑Pattern，作为类比，说明构架设计是怎么建模的。

《5G》这个例子之所以好，关键在于如下几个要素：

1.它是个真实的设计

2.它是个部分成功的设计，至少现在已经有符合这个架构的系统用起来了

3.它是个未完全成功的设计。

第三点特别重要（但以前两点为前提）。这才是我们做架构设计面对的真实情况。成功以后的大部分所谓总结，其实都是在乱提取Pattern而已。知道曹操打赢袁绍的之后你当然一堆解释曹公如何雄才大略，官渡的时候你不投降本初大人就不错了。架构设计考量的都是面对“未知”的时候，如何抓到重点的问题。如果你跟着别人干，就会觉得这没有什么了不起的，觉得自己“天然”就会这样选择，等你

自己干了，你就发现，最难的其实是这个选择。别说5G这样一个大型系统了，大把人连自己（或者你儿子）高考应该报哪个专业估计都不知道应该怎么选。

所以，当你要做第五代移动通讯系统的时候，你首先应该从哪里入题？

拉到最高，“为了丰富人类的沟通和生活”？那是市场部的人干的，不是架构师干的。

务实一点，“优化Node-B空口功率”？那是Node-B开发组干的，也不是架构师干的。

《5G》的选择是什么呢？

Use Case！

换句话说，理想。

你对现在的无线系统不爽的地方是什么呢？什么功能是你最不爽的呢？反映在生活的什么地方呢？这是原始需求，《5G》具体怎么推的读者可以看原文（主要是第二章），但我提议大家注意这几个点：

1.它不是说“我说的就是对的”，但它也不会说得模棱两可，它是给出它的意见，然后

让3GPP等标准组织协同讨论，取得一致（这一点没有呈现在原文中，原文取了这个共识的达成之后的标准文本），成为设计的原始需求

2.它没有找任何权威做需求的输入，这个需要从“被指挥”位置上成长起来的工程师注

意了：大部分正经的架构设计，原始需求来自原始的利益驱动，而不是来自某个权威（这里说的权威包括而不限于：领导，市场部的表述者，行业专家），依赖权威的做法要不就是你自己倒霉，要不就是把设计任务推给这个权威。

3.它从不同的维度去总结这个需求，而不是一个“需求列表”

最后这点我们可以打开看看，原文是这样抽象的：

首先是一个总的对当前网络的抱怨列表：

版权原因，原谅我不截全图，读者自己买书看。下同。

然后分成8个市场域：

最后再压缩为三种类型：

•xMBB：升级的移动宽带，让智能终端上网更快（这个需求重带宽）

•URLLC：高可靠，低时延网络，让比如车载这样的系统反应更快（这个需求重时延）•mMTC：低带宽，多连接网络，让比如IoT这样的系统可以更密集（这个需求重连接数）

你看这个逻辑链都构架在非常高的抽象上，连如何组网，用什么协议，都一字不提，但它仍是一个严格的逻辑。这最后确定的三个业务类型，直接控制后面所有的设计。

而且这些需求作为原始的标杆（OR，Original Requirement），对于后面每个设计的对比作用是非常明确的，比如这个Mobility，指标是“公里每小时”，比如设定200km/h，那么我们就会直接去对比：你的小区切换速度，要达到什么要求？这个约束，就会成为一个非常具体的设计需求了（DR，Design Requirement）。

然后我们看看后面分的设计层面：

•利益链定义

•频谱分配和信道模型

•网络架构：分层，分片，软件模型

•安全架构

•网管

•关键协议

•验证和评估模型

这个本质上是把“实现”作为一个中心，取各个关键的维度（所谓的视图，View），独立对那个维度进行建模，用那个维度形成一个整体约束。在

xMBB/URLLC/mMTC这个维度约束的时候，每个实现者其实有无数的自由度，但为了实现这些能力的提升，你首先得占更大的频谱，否则所有东西都不用谈的，所以，技术上首先的建模是频谱分配。这马上会面对这个约束：各国的频谱分配是不一样的，那我们就先来设计有多少中分配手法：

只要你落入这里其中一种类型，我们就按那种类型来进行后面的设计。如果你不在这个范围内，那不好意思，你自己玩去。这样高冷是不是一定行呢？当然不是，太高冷就把自己玩糊了。正确的方法是定义出第一个版本后，拿去和所有成员公司Bargain，大家不断贡献进来“具体情况”，最后执笔定义架构（标准）的人取一个Tradeoff，变成成特定的要求。让大多数压倒少数，形成一层共识。

架构师总是需要在错误和共识之间不断整合资源和信息，才能推动设计前进。只有不懂的人才会用力过猛，认为架构师是不犯错的。