【实践】网络货运平台的技术架构，其战略层和战术层设计原则，避免走哪些弯

时间：2023-03-17 01:52:01 | 来源：电子商务

时间：2023-03-17 01:52:01 来源：电子商务

市面上很多网络货运平台，可以应付部分省份的资质申报。但在运营层面是否好用，是否能灵活的、低成本的二次开发，选择适用的技术架构是关键。本文适合已经获得网络货运资质的企业管理层，技术总监类岗位阅读。

在网络货运领域，技术架构，是将货运的监管需求和业务需求转变为技术实现的过程。技术架构解决的问题包括了如何进行纯技术层面的分层、开发框架选择、语言选择（这里以 JAVA 语言为主）、涉及到各自非功能性需求的技术点（安全、性能、大数据）。技术架构是确定组成应用系统实际运行的技术组件、技术组件之间的关系，以及部署到硬件的策略。本文参考了，菜鸟风控系统的网络技术专家胡斌的观点，以及结合笔者在网络货运平台的开发经验，做技术框架的简单说明。

技术架构面临最大的挑战是“不确定性”。在技术架构上，很多时候就会面临这种选择。是要选择业界最新的技术？还是选择团队最熟悉的技术？如果选择最新的技术，遇到新技术出了问题怎么解决？如果选择目前熟悉的技术，后续技术演进怎么办？这些都是架构师在做技术架构过程中需要考虑的。

货运业务在千变万化、技术在层出不穷，没有一套通用的技术架构模式来适用所有的系统。那么，我们如何保证在做技术架构时，能够实现一个稳定、出色的系统。面对这些“不确定性”时的架构设计问题，这里从战略和战术两个层面来提供一些设计原则。战略层提供的是技术架构的方法和思路，属于顶层设计；战术层提供的是技术架构的技术实践方式，更偏向详细设计。

首先，简单说明一个技术框架选取不够谨慎的真实案例，这也是一次在技术选型层面走弯路的典型分享：

（1）起因：笔者在2017年开始，帮公司招聘了大约30人的研发团队，专注无车承运人平台（2020年开始，更名：网络货运）的研发。最早采用c#开发语言，以及.NET Core的软件开发框架，app重点采用RN混合开发框架。

（2）问题：近4年的实践，也服务了200多家网络货运企业。在部分企业，获得网络货运资质后，开始正式做网络货运的运营。在实践过程中，月度运费高于1亿以上，就会出现各类技术问题，比如：并发量问题、系统卡顿、数据丢失等问题。严重影响，中大型客户，在实际运营中的体验。

（3）解决：即便技术团队，无数夜晚的加班，用心修复BUG，近10次的技术重构，500次以上的更新迭代，依然无法根除系统不稳定的情况。这类问题，我们不是最严重的，但这也是很多技术供应商，共同面临的问题。导致该问题的核心原因：最初的团队，只擅长.net相关的技术，对其他技术无法把控。但.net相关开发人员，在成都市场，乃至北上广深，都面临转型的情况，出现牛人不好找，新人不好用的局面。

（4）反思：这个弯路，无论是网络货运技术供应商的同行，还是即将采购平台源码做二次开发的企业客户，都应该避免。不是每一个人都舍得弃用，已经相对熟悉的方案；弃用，就代表着重头开始。弃之可惜，食之无味，是最难受的。

新的改变：基于这类情况，笔者于2020年12月再次组建一个25人的研发团队，重新研发一套全新的网络货运平台，以满足新老企业，在运营层面稳定性的需求。新的技术总监，结合以往对物流供应链、钢铁大数据、OA办公的研发经验，重新选了新的开发框架。PC端，采用java开发语言；app采用flutter框架开发；小程序采用uniapp的跨端开发框架。（技术框架的选型说明有6页，本段仅简单提一下）

Java是一门面向对象编程语言，不仅吸收了C++语言的各种优点，还摒弃了C++里难以理解的多继承、指针等概念，因此Java语言具有功能强大和简单易用两个特征。Java的优势，学过计算机的都大致理解，该部分不需要重点阐述。app采用的技术框架，简单对比一下 ：

RN框架（Facebook开源）
（1）React Native兼容性较差，版本升级难度大；
（2）重点支持安卓和ios。

flutter框架（Google开源）
（1）谷歌在创建flutter框架，也重点参考了RN的情况，产生灵感和开发思路，避免兼容性差，版本升级成本高等因素。
（2）支持安卓，ios，web，mac，window，嵌入式。

新的结果：平台高速的版本迭代，以及客户实践证明：无论新旧技术，适合为王，可掌控为皇！不到1年时间，在没有做任何广告推广的前提下，新的平台逐步征服了中大型专业客户，在竞争激烈的网络货运技术供应商市场中，赢得了一席之地。平台的合规性，不仅体现在业务层面的管理，也体现在功能细节的差异性。运营层面的多元化，需要软件产品，逐步适配。摒弃4年的开发经验，优胜劣汰，吸取以往的经验，避免走了很多弯路。以下简单说明一下，技术框架战略层的设计原则。

战略层设计原则

战略层的设计原则就是：合适原则、简单原则、演化原则。

1.1 合适原则

技术人员有一种很强的技术情怀，就是在做设计的过程中，很希望挑战新的技术、在项目中采用最新的框架、或者自己重造一个比业界的还要牛的轮子。这样才能够显示出自己的优秀，以至于不让自己显得那么平庸。比如，在项目中重新造一个能够解决亿万级数据的新的 xx 流式计算技术，比 flink 还要牛一百倍；又或者在项目中使用最新的 xx 技术，能让系统承担亿级用户的访问。

如果在设计过程中一味追求新技术，往往失败的可能性很高。因素：

（1）没有那么多人，却想干那么多活

现实环境中我们一个业务团队可能就十几个人，项目工期短、上线要求快。在这种情况下，如果还要抽调几个人去研究、搭建、维护新的技术框架，对于项目势必会造成延期的影响。

（2）没有那么多积累，却想一步登天

很多业界领先的方案，不是一帮优秀的开发加在一起，加班加点就能做出来的。而是经过几年时间的发展才逐步完善和初具规模。如果我们也想自己做一套类似的技术，不是说不可能。我们需要集合当下的技术实力、技术积累，做出适合自己团队情况的技术评估。

（3）没有最新，只要最合适

所有新的技术刚出来都是打着比旧技术拥有更加出色的性能、提供更加优秀的扩展性。是不是使用新技术，就能解决一切问题了？新技术的出道，势必是解决某一场景下的问题，并不是一味万能良药。只有了解清楚每种技术的产生背景，适用场景，才能出一个对自己项目最优的选择。技术选型没有最新，只有最合适。但无论选用哪种技术框架，市面上这类人才需能把控，且能招聘到，才是基本前提。否则再先进或陈旧的技术，一旦团队换人，找不到合适的人才，就无从适应。

总结一下，合适原则就是适合优于业界领先。

1.2 简单原则

我们总是希望能将我们的软件设计的精美、宏大，这样才能彰显我们系统的复杂度和难度。我们是不是会遇到这样的场景，在做设计方案的时候，如果一个解决方案很简单，而且能很快的满足需求。在评审方案时，就会有人觉得这个方案是不是太简单了，没有什么技术含量，是不是需要再设计的复杂一点。

系统是不是一定要设计的复杂？在回答这个问题前，我们先看下软件领域的结构复杂性和逻辑复杂性。

（1）结构复杂性

结构复杂的系统有两个特点：第一，组成的组件数量很多；第二，这些组件之间的关系很复杂。如下图：

图 1

结构上的复杂性存在的第一个问题是，组件越多，就越有可能其中某个组件出现故障，从而导致系统故障。假设组件的故障概率是 1%（有 1% 的时间不可用），那么 2 个组件的系统可用性是 99%*99%=98%，5 个组件的系统可用性是 99%*99%*99%*99%*99%=95%，两者相差 3%。说明组件越多，系统稳定性就越差。

结构上的复杂性存在的第二个问题是，某个组件改动，会影响关联的组件。比如上图中 C 组件发生改动，会影响 A、B、D，而 A 又会影响 E。这样就会形成一连串的多比诺效应。

（2）逻辑复杂性

意识到结构复杂性的问题后，只要减少组件就能让系统结构变简单？这样做还是行不通，原因在于除了结构的复杂性，还有逻辑的复杂性，如果一个组件的逻辑太复杂，通用会带来问题。

我们试想一下，把淘宝的所有功能都在一个组件中实现，可以想象这个系统要有多庞大：几百人维护一个系统、代码分支几十个、需求变更应接不暇、不同分支的回归测试、修改一段代码可能影响整个系统的运行等等。这些场景相信大家都不希望看到的。

总结一下，简单原则就是大道至简。

1.3 演化原则

软件架构和建筑架构很多相同的地方，架构这个词也是从建筑领域借鉴过来的。比如，软件架构描述的是系统的结构、以及各模块之间的关系。而建筑结构描述的是一幢建筑的结构，以及建筑内部各部件如何有机的组成。

但是，软件架构和建筑架构有一个本质上的差异：那就是建筑一旦完成就不会再变，而软件却需要根据业务的发展不断的变化。对于建筑来说，永恒是主题；而对于软件来说，变化才是主题。

如果没有意识到“软件架构需要根据业务发展不断变化”这个本质，在做架构设计的时候很容易陷入一个误区：试图一步到位设计一个软件架构，期望不管业务如何变化，架构都稳如磐石。如果是按照这样的目标是设计，一开始上来就做出一套看似是终极的方案，投入庞大的资源做各种预测、分析。结果是投入巨大的资源、开发周期漫长，最终跌跌撞撞落地的系统，却发现已经无法很好的满足现有的业务。

所以技术架构设计需要一个过程：

首先，要满足当前的业务需求进行技术架构设计

其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使架构逐渐完善。

第三，当业务发生变化时，架构要扩展、重构、甚至重写；代码也许会重写，但有价值的经验、教训、逻辑、设计却可以在新架构中延续。

总结一下，演化原则就是演化优于一步到位。

战术层设计原则

战术层的设计原则分为 3 部分：高并发原则、高可用原则、业务设计原则。这些原则是对技术架构设计过程中提供详细的指导思路，帮助你做技术选型、技术拆分。

2.1 高并发原则

设计高并发的系统，需要考虑以下几个方面的设计：无状态、拆分、服务化、消息队列、数据异构、缓存。

（1）无状态

• 无状态应用，便于水平扩展。
• 有状态配置可通过配置中心实现无状

（2） 拆分

• 系统维度：按照系统功能、业务拆分，比如购物车、结算、订单等。
• 功能维度：对系统功能再做细粒度拆分。
• 读写维度：根据读写比例特征拆分；读多，可考虑多级缓存；写多，可考虑分库分表。
• AOP 维度：根据访问特征，按照 AOP 进行拆分.
• 模块维度：对整体代码结构划分 web、service、dao。

（3）服务化

• 服务化演进：进程内服务 - 单机远程服务 - 集群手动注册服务 - 自动注册和发现服务 - 服务的分组、隔离、路由 - 服务治理。
• 考虑服务分组、隔离、限流、黑白名单、超时、重试机制、路由、故障补偿等。

（4）消息队列

• 目的：服务解耦（一对多消费）、异步处理、流量削峰缓冲等。
• 大流量缓冲：牺牲强一致性，保障最终一致性。
• 数据校对：解决异步消息机制下消息丢失问题。

（5）数据异构

• 数据异构：通过消息队列机制接受数据变更，原子化存储。
• 数据闭环：屏蔽多重数据来源，将数据异构存储，形成闭环。

（6）缓存应用

• 用户层：DNS 缓存、浏览器 DNS 缓存、操作系统 DNS 缓存、本地 DNS 服务商缓存、DNS 服务器缓存、客户端缓存、浏览器缓存、APP 客户端缓存。
• 代理层：CDN 缓存（一般基于 ATS、Varnish、Nginx、Squid 等构建，边缘节点 - 二级节点 - 中心节点 - 源站）
• 接入层：Nginx 的 Proxy_cache 代理缓存，或者 Nginx+Lua+Redis 做业务数据缓存。
• 应用层：页面静态化、业务数据缓存（Redis/Memcache/ 本地文件等）、消息队列
• 数据层：NoSQL（Redis、Memcache、SSDB 等）

2.2 高可用原则

1. 降级

• 降级开关集中化管理：将开关配置信息推送到各个应用。
• 可降级的多级服务：如服务调用降级为只读本地缓存。
• 开关前置：如 Nginx+Lua 配置降级策略，引流流量；可基于此做灰度策略。
• 业务降级：高并发下，保证核心功能，次要功能可由同步改为异步策略或屏蔽功能。

2. 限流

• 目的：防止恶意请求攻击或超过系统峰值
• 恶意请求流量只访问到 Cache
• 穿透后端应用的流量 Nginx 的 limit 处理
• 恶意 Ip 使用 Nginx Deny 策略或者 iptables 拒绝

3. 可回滚

• 发布版本失败时，可随时快速回退到上一个稳定版本。

2.3 业务设计原则

• 防重设计
• 幂等设计
• 流程定义
• 状态与状态机
• 后台系统操作可反馈
• 后台系统审批化
• 文档注释
• 备份

技术架构图

技术架构图是将系统的技术方案、技术选型通过视图的方式进行展现。技术架构图分为两类：一类，功能需求技术架构图（逻辑架构图），是描绘如何通过技术组件来实现系统产品功能的图。另一来，非功能需求技术架构图（物理架构图），是描绘如何通过物理部署的来实现系统运行的图。

3.1 逻辑架构图

功能需求技术架构图以产品架构图和应用架构图为基础。实现每个功能点需要使用什么技术、技术实现逻辑如何，就体现在技术架构图上。功能需要技术架构图绘制可以按照“整体 - 局部 - 整体”的思路实现。

1. 整体

首先可以按照应用架构图的应用分布得到应用分布框架。如下：

图 2

2. 局部

在整体框架的基础上，对每一个局部的子系统进行详细的技术实现的表达。子系统的技术架构图中需要展示每个子系统使用的技术组件，比如（缓存技术、消息中间件、流程引擎、流式计算框架等等）。同时，这些技术组件是如何实现业务功能，需要清晰的展示技术实现逻辑。

下图是对风控系统中的实时引擎、离线引擎、准实时引擎三个子系统的进行的技术架构。在实时引擎中，主要使用 RuleEngine（规则引擎）作为技术特点，这里就重点列出 RuleEngine。准实时引擎使用 Blink 作为流计算的技术框架，并概要的展示了计算逻辑。

图 3

3. 整体

在完成每个子系统的技术实现后，最终进行一次整合，绘制一张总体的系统技术架构图。各子系统之间通过服务接口、数据库、缓存或消息中间等技术实现数据交互，以此将打通各个子系统，实现最终整个产品，在数据、技术的串联。

图 4

3.2 物理架构图

物理架构偏重于网络设计、集群设计、中间件设计、数据存储设计等基础软硬件的设计架构。非功能需求的技术架构图重点在于展示企业系统在物理上是如何部署。物理架构规定了组成系统的物理元素、物理元素之间的关系以及他们的部署策略。物理架构反映出软件系统动态运行时的组织情况。从物理架构图中，我们能够全局的得知整个系统是如何从流量访问、数据流转、数据存储到技术组件的运转。

图 5

总 结

我们从架构的本质开始，分别对业务架构、产品架构、数据架构、应用架构、技术架构的设计提供了一些思路和原则。这些思路和原则在进行架构设计和画架构图的过程中提供一些指导帮助。最后我们再来思考一个问题，好的软件架构是规划还是演化出来？

架构规划对架构的影响是很重大的。好的架构，系统的性能和质量都将很高。架构设计的质量直接影响架构后续向好的方向演化的难易程度。架构设计如同城市规划一样，缺少规划将难于演化。在现有规划的基础上进行演化，我们无法得到普适的架构，但可以得到确定领域的通用架构，可以在特定领域通过演化使架构逐步优化，帮助业务快速的发展。

本文不做任何商业推广，仅做技术交流与分享。欢迎网络货运的技术大牛，共同交流与学习，索取阔天科技旗下<货超多>在研发网络货运平台，技术框架采用的细节说明。

关注货超多，汲取业内精华