本文上周开始写的，一直没有写完，今天临时要给人讲一个逻辑，需要参考，先放出来，后续写完后，读者就不会看到这个提示了。
架构设计这种东西，只能从实例里面学。用抽象的总结描述架构设计的方法，懂的人听了没用，不懂的人听了不知道在说什么。但举真实的例子很难。因为能公开的例子，要不太旧，没有什么意义；要不太新，基本上都会有保密问题。
最近跟论文的时候看了一本书，本周刚看完，感觉完全能解决我前面说的问题，推荐给有兴趣的各位：
这完全是一份5G网络构架设计说明书，如果你需要一个参考，考虑你的架构设计怎么做，把他作为模板来学习就行了。
当然，如果你只能学习形式，不能形而上地考虑逻辑，非要形而下考虑形式。只能学习人家的章节，那当我没说过。
下面做一个阅读赏析。为了讨论的方便，我们把上面这本书，或者架构设计说明书，叫做《5G》。
在讨论前，先说说我的背景，我工作早期（二十多年前吧）做过几个无线系统的平台支持，比如GSM BSC/MSC的主控板的驱动，PDCP的OS平台提供等等，最近几年偶尔也会解决一两个相关产品的操作系统层的问题。所以充其量是对其中的名词术语和要解决的问题“有所耳闻”，对于无线产品设计的细节基本上是个外行。所以我这里并不是讨论5G系统应该如何设计，我也没有能力评判那个设计做得好不好。我是要通过这个设计考虑的逻辑Pattern，作为类比，说明构架设计是怎么建模的。
《5G》这个例子之所以好，关键在于如下几个要素：
- 它是个真实的设计
- 它是个部分成功的设计，至少现在已经有符合这个架构的系统用起来了
- 它是个未完全成功的设计。
第三点特别重要（但以前两点为前提）。这才是我们做架构设计面对的真实情况。成功以后的大部分所谓总结，其实都是在乱提取Pattern而已。知道曹操打赢袁绍的之后你当然一堆解释曹公如何雄才大略，官渡的时候你不投降本初大人就不错了。架构设计考量的都是面对“未知”的时候，如何抓到重点的问题。如果你跟着别人干，就会觉得这没有什么了不起的，觉得自己“天然”就会这样选择，等你自己干了，你就发现，最难的其实是这个选择。别说5G这样一个大型系统了，大把人连自己（或者你儿子）高考应该报哪个专业估计都不知道应该怎么选。
所以，当你要做第五代移动通讯系统的时候，你首先应该从哪里入题？
拉到最高，“为了丰富人类的沟通和生活”？那是市场部的人干的，不是架构师干的。
务实一点，“优化Node-B空口功率”？那是Node-B开发组干的，也不是架构师干的。
《5G》的选择是什么呢？
Use Case！
换句话说，理想。
你对现在的无线系统不爽的地方是什么呢？什么功能是你最不爽的呢？反映在生活的什么地方呢？这是原始需求，《5G》具体怎么推的读者可以看原文，但我提议大家注意这几个点：
- 它不是说“我说的就是对的”，但它也不会说得模棱两可，它是给出它的意见，然后让3GPP等标准组织协同讨论，取得一致（这一点没有呈现在原文中，原文取了这个共识的达成之后的标准文本），成为设计的原始需求
- 它没有找任何权威做需求的输入，这个需要从“被指挥”位置上成长起来的工程师注意了：大部分正经的架构设计，原始需求来自原始的利益驱动，而不是来自某个权威（这里说的权威包括而不限于：领导要求，市场部的表述，某些权威技术的说法），依赖权威的做法要不就是你自己倒霉，要不就是把设计任务推给这个权威。
- 它从不同的维度去总结这个需求，而不是一个“需求列表”
最后这点我们可以打开看看，原文是这样抽象的：
首先是一个总的抱怨列表：
版权原因，原谅我不截全图，读者自己买书看。下同。
然后分成8个市场域：
最后再压缩为三种类型：
- xMBB：升级的移动宽带，让智能终端上网更快
- URLLC：高可靠，低时延网络，让比如车载这样的系统反应更快
- mMTC：低带宽，多连接网络，让比如IoT这样的系统可以更密集
你看这个逻辑链都构架在非常高的抽象上，连如何组网，用什么协议，都一字不提，但它仍是一个严格的逻辑。这最后确定的三个业务类型，直接控制后面所有的设计。
然后我们看看后面分的设计层面：
- 利益链定义
- 频谱分配和信道模型
- 网络架构：分层，分片，软件模型
- 安全架构
- 网管
- 关键协议
- 验证和评估模型
这个本质上是把“实现”作为一个中心，取各个关键的维度，独立对那个维度进行建模，用那个维度形成一个整体约束。在xMBB/URLLC/mMTC这个维度约束的时候，每个实现者其实有无数的自由度，但为了实现这些能力的提升，你首先得占更大的频谱，否则所有东西都不用谈的，所以，技术上首先的建模是频谱分配。这马上会面对这个约束：各国的频谱分配是不一样的，那我们就先来设计有多少中分配手法：
只要你落入这里其中一种类型，我们就按那种类型来进行后面的设计。如果你不在这个范围内，那不好意思，你自己玩去。这样高冷是不是一定行呢？当然不是，太高冷就把自己玩糊了。正确的方法是定义出第一个版本后，拿去和所有成员公司Bargain，大家不断贡献进来“具体情况”，最后执笔定义架构（标准）的人取一个Tradeoff，变成成特定的要求。让大多数压倒少数，形成一层共识。
细化到这个程度，就可以结合上面的xMBB/URLLC/mMTC的需求，把不同的业务分配上去。
有了这个分配，我们就可以进一步控制我们在协议栈上的要求的：
你看，既然你要支持不同的业务属性，我就从MAC层开始把你的业务类型拆成多个维度，这已经是对细节设计的直接约束了。但它的逻辑仍是清晰的：你有办法在一种类型的MAC层上，实现带宽和时延的同时提高吗？既然我们承认这一点不成立，我们又要求必须同时至此和URLLC和xMBB，那协议从MAC层分离不就是比自然的选择？
没有这个层面的设计，你光从“网卡”这个主题上来进行建模，怎么会可以找到“原始需求”？
然后，既然你在MAC层上分配调度策略，总要找到一个“属性”可以把这个要求落到不同的MAC和PHY上吧？这个概念就需要从“连接”这个层面传递下来：
为了做到这一点，网络就需要根据业务流动态改变内部网元的部署。但这一点基本上是做不到的。这样SDN就成为必须的选择了：
这其实和数据中心是很像的，就是IaaS承载SaaS，然后承载业务。只是SaaS换成了VNF，在I层上部署网络单元，但在业务上形成不同的需求，由于它对QoS要求很高，所有需要专门的网络控制协议，通过Controller下发下去（这样就有构成类似OpenFlow那样的数据面和控制面分离要求了）。
对运营商来说，当然希望I层和N层可以解藕，但设备提供商显然没有什么动力。这个地方妥协的结果就是个模糊的地带：首先设备提供商仍要解决它的VNF可以动态部署的问题。而运营商至少可以把服务器的采购独立出来。最终交换机和基站是不是那么简单可以控制，这个事情就要看双方的博弈了。但无论结果是什么，架构设计这里仍解决了网元单元根据业务形式进行动态调整这个需求——至少让这一点成为可能。
具体细节读者去看原文吧，我再说详细一点，就变成抄人家的原文了。
总结起来，所谓4+1视图，只是一个大致的方向而已，一个构架设计，具体用什么视图，完全取决于先建哪个逻辑链是最高效的。认真看看这个设计中每个逻辑链是怎么建的，看看人家面对的未知比你多还是比你少，你就知道在稀疏的约束上，每个具体的逻辑可以如何设计。它不能直接告诉你“怎么做”，但如果你真心做你的逻辑链设计，这个参考价值是很大的。
最后再强调两点。第一，在这个建模中，利益链的建模放在所有模型的最前面，这是一个证据——以我的观点，进行高层的设计，这几乎是躲不开的，不要因为我们是做技术的，就可以不管利益分配了。
第二，推荐很少正经写文档的人好好看看这本书的第一章。我见过太多的所有“务实”的工程师都是跳过这一章的，忽略这一章的人基本上都是不重视逻辑链的。如果你上来就写第二章，我作为读者，就会有这样的疑问：你是谁？你代表谁？你说这些东西干什么？你说的是完整的逻辑吗？你的范围在哪里？你想证明什么？你证明这个逻辑的整个逻辑链是什么？为什么你要这样放这些章节？……你连这些问题都不想，我有什么办法相信你里面的基本逻辑链是靠谱的？逻辑链不靠谱，浪费巨大的脑力看你的逻辑，完全就是浪费时间。
最后说一些感受啊。很多人都说我们国家5G技术领先了，但这种架构级的表述，实话说，我看到都是欧洲的研究机构出的啊（也许是我孤陋寡闻，请有经验的读者指点我读一下国内的对应的文档。请不要告诉我这是保密的，架构设计基本上是无法完全保密的，否则它就不是架构设计了）。所以，领先可以表现在有很多专利，可以表现在有很好的工程能力，但只有这些，没有构架设计和维护能力，要做到独立自主和创新，那也是远远不够的。
但反过来也可以反思，欧洲现在也很难独自提供5G解决方案了，说起来，如果聚焦在架构控制上，不培养工程实体，架构师反过来也会受制于工程能力。
这也永远是个Tradeoff的问题。
来源：oschina
链接：https://my.oschina.net/u/4415996/blog/4436246