架构没有绝对的最好，设计过度或者没有设计都不是我们想要的。恰到好处，同时又能与时俱进是我们所追求的好架构。pon终端产品从诞生到现在，已近十年，年发货量千万以上，期间经历过几次代码调整，不过总体架构并未有大变化。在这里必须向我们的架构师，开发和强大的测试团队致敬，增加和修改了成百上千条需求，版本依然如此稳定。

    pon终端是连接互联网的光终端二三层交换小盒子，是万物互联的基础设备之一。终端业务种类丰富，包括上网、电视、语音，无线，有线等。业务场景复杂，功能代码更复杂。比如交换芯片的驱动程序，linux内核桥路由转发逻辑，地址控制协议，组播控制协议，防火墙，QoS，各种上层应用。  (备注:此处应有一个软件架构图)。模块之间关系复杂，只有经验丰富的研发人员才清楚一个业务开通时内部究竟发生了什么。为了提高研发效率，梳理和优化软件结构就很必要了。

    这里想分享的是我们这一年对核心模块做的梳理和优化，主要是版本合一、配置与版本分离、平台化，以及对抽象的思考。

1.版本合一

    光终端细分为多种上行制式，gpon，epon，10g epon等。北向接口的控制协议不同，硬件实现上携带不同种类光模块。之前从展现层到业务层，再到底层驱动层的代码，多少都会涉及到上行方式，这样带来几个问题，一是业务层或展现层代码重复代码很多，Gpon上行写了一套，Epon上行又写了相似的一套，重复代码是万恶之首，我们工程里的重复代码确实带来的不少的维护工作量。二是版本数量多，Gpon和Epon上行产品大概有90%是相同功能，之前我们的做法是共用一个主干基线，用宏控制分别做出Gpon的和Epon的版本，测试阶段对2个版本分别做系统通用集测试，入网测试也是一样。

    如果做到1.对上层应用隐藏住上行方式的差异，2.版本自适应上行方法。那么一来减少部分重复代码重，二来版本数减半。

    我们的做法是增加一层上行方式适配层，将不同上行方式的接口统一，对上层业务隐藏上行方式的差异。这一层的主要函数包括(待补充函数列表，以及增加这一层之后的软件架构图)。

    这样优化之后的效果，一是网管控制协议模块的参数节点树展示层的代码量减半，二是生成的版本数量减半。减少了开发人员维护工作，也减少测试工作。

2.配置和版本分离

    我们发货的版本一般由两部分组成，一部分是预配置数据，一部分是可执行程序。不同省份的定制版本的差异主要由预配置数据控制。修改某个配置数据，需要升级完整版本，这就意味着又要经过一轮机关重重的现场入网测试。

    针对于此，我们做了配置与版本可分别单独升级的设计，调整了内存数据库的代码结构，一是修改了数据配置文件的结构，增加配置文件的版本信息，二是增加一个配置文件升级管理模块，负责加载配置的升级文件。(待补充:实现这个功能后内存数据库模块的结构图、预配置文件设计图）。

    这样优化的效果是:当某些需求可以通过配置数据控制时，我们将只升级配置文件，版本不动，这样就节省了原本耗费人力的新版本入网测试环节。

3.平台化

    国际国内pon终端的需求千差万别，即便是国内几大运营商的需求差异也很大。在交付的压力下，经常会通过拉分支基线来完成，再加上有时未及时回归主干，久而久之基线就多起来。分久必合，合久必分，分分合合，合合分分，这样带来了不小的工作量。

    如果能将基础代码平台化，丰富的功能，良好的扩展性，可以共享的安全合规自检等，都将成为快速实现产品的好帮手。

    为了方便产品使用平台，平台的软件目录结构实现如下 图所示(待补充:平台软件目录结构图)。目录主要分为:1.平台核心功能；2.组件包；3.产品代码包。

    平台在设计之初曾争论过平台究竟是要做成大而全，还是小而灵活。目录结构究竟要不要区分产品包、核心包。

    我们目前做法是平台核心功能做的小而灵活，以dns为例，平台核心代码只实现rfc标准流程，在某些点上提供钩子。而由产品实现定制需求。

    另外，由于还有管理方面的考虑，目录结构设计上也会有一些管理的影子。

    这样做的效果是国内多家运营商的pon终端使用用统一平台，再加上各自的定制代码，合起来出一个版本。

    为保证质量， 平台团队交付代码给产品团队时，还要给出单元测试代码。

  这是我们从去年底就开始的一项任务，对于终端产品来说，理想的平台究竟是什么样的，我们还在摸索，也希望能有机会和高手探讨这个话题。

4.对于抽象的思考

    为了能让开发人员将注意力集中在业务本身，而不是陷于某些相关性不太大的细节上，比如编程语言的细节上，我们尝试抽出领域语言，并且使用DDD方法对各个领域建模。

    比如网络连接模块，提供了如下一些服务: wan连接创建、修改、删除、查询。网络连接消息订阅。(备注:提供一下接口列表)。不再向外界暴露地址协议交互过程等细节。

    但在这样做的过程中我们也有疑惑，我们的产品是嵌入式产品，主要编程语言是c语言。而前文也介绍了，终端的业务种类很多，如果大范围推广领域语言，开发人员的要求似乎更高了，需要理解领域语言，并且具备较好的业务抽象能力。

    5.总结

    以上是我们pon终端在过去一年对架构方面做的优化和思考，希望能有所帮助，更希望能和大家交流，相互学习，让我们的软件更符合可实现，可扩展，可测试等好的架构设计的标准。