移动化浪潮下，谈谈多端优化以及延缓架构腐化

不知不觉移动的发展早已是驱动大量技术升级的主要力量，民众已然享受到移动化时代给生活带来的各种便利：购物、饮食、打车、转账等等，然而开发者却面临着移动端的诸多考验：多分辨率适应、不同网络环境的加载优化、Web 和 Native 之争、移动安全等等，并且加上移动技术的日新月异和快速更迭，大量开发者被新需求和新技术冲击下找不着前进方向。

2016 年 12 月 2-3 日， ArchSummit 全球架构师峰会将在北京举行。本届大会组委会策划了“日新月异的移动架构”专题，并邀请了阿里巴巴资深专家肖恩老师担任该专题出品人，我们借此机会采访了肖恩老师，他为我们分享了目前对移动架构的趋势见解和经验教训，希望可以为大家带来启发。

受访嘉宾介绍：

肖恩，毕业于浙江大学，2008 年加入阿里巴巴。曾主导了中间件平台框架Dubbo 的研发、B2B 网站服务化改造等工作。自2011 年开始参与阿里集团的应用产品研发，先后负责过来往、本地生活等团队多款无线应用的技术研发管理工作。2013 年开始参与智能设备及新技术的研究工作，涉及语音图像蓝牙和软硬件一体产品及App 的设计研发。目前在B2B 技术部负责阿里乡村的无线技术团队及整体性架构支持工作。开源爱好者，早期的iOS 1.x 原生应用开发者，业余无线电爱好者，关注APRS 的发展。

InfoQ：能否介绍智能生活与移动架构在技术要求上有哪些异同？您是如何兼顾这两方面的知识的？

肖恩：手机上的 App 应该是现代智能生活解决方案的一个重要部分，App 把手机变成了一个高级的遥控器。除了替代传统遥控器的开关功能，App 借助手机或者平板电脑的特性，在信息展示、设定和触达方面有天然的优势，确保了整体方案的用户体验。

在技术架构要求上，App 的产品功能设定其实更纯粹，作为端的一部分，配合云端和设备端来完成整个链路的闭环。大厂商智能设备 App 在架构需要额外考虑的是作为“航母”接入外部三方功能的一系列架构挑战。譬如我们当时做的 App，为了方便厂商或者独立 ISV 进行自行开发和接入，以便于他们来参与部分的定制工作，因此我们必须提供一套完善的插件框架，结合 Hybrid 的展现技术，暴露出 JavaScript 的访问控制 API。整个 App 有点像小型的应用商店，因此必须解决一整套的开发、测试、安全检测、沙盒控制和功能上下架等功能。这又是前端后端的一整套方案，只看 App 应用就显得不够完整了。

至于对技术知识的要求，如果有良好的接口设计和模型定义，那么云端、设备端和应用端的三端开发人员是可以不用知晓对方太多的底层细节知识的。当然有少部分人必须同时具备三端的经验，否则设计整个系统的时候就有很大的问题。

就我个人而言，一直比较有运气。在工作一开始就从事服务端开发，做了一些企业应用和框架中间件产品；07 年以后第一次接触 iPhone 应用开发，到最近几年都有机会参与一些重要的 App 开发工作；而电子电路则是自己从初中开始的兴趣爱好，多年来一直在学习提高，从原理上来看这些不同知识背后道理其实都是相通的。

InfoQ：从"iPhone OS"到"iOS10"的正式版发布，作为早期原生应用的开发者您有什么感慨？在这个过程中您遇过怎样的惊喜和遗憾？

肖恩：作为早期的 iOS 原生应用开发者，还是有过一段傲娇的时期的。早期没有应用商店和开发文档，都是靠一个修改过的 class-dump 工具和苹果 Cocoa 桌面版的 API 文档来进行摸索开发。有必要的话，还会去逆向 iOS 自带的应用来了解 API 的调用方式。这导致了那时候 App 开发有相当的门槛，因此有一定的技术自豪感。

那时候早期的开发者都混一个叫做什么锋的论坛，还有一个内部的 QQ 群。而且我还清楚的记得，那时候 Holly 发布说可以有一个原生键盘的中文输入法放出来，很多人纷纷回帖说是骗子。

而自从 iOS 2.0 开始苹果逐步开放 SDK 以后，这些技术门槛就逐步消除了，同时应用商店的审核对于第一批的“自由”开发者来说，存在不小的限制，因为很多私有 API 你看得到，但是不能使用了。因此兴趣更多地转移到 App 的产品设计上了。

InfoQ：能否为大家解释“App 会越做越小，但是功能和方向上会越来越超越 App”这个趋势？这对无线应用的技术提出了怎样的要求？

肖恩：我对这个问题的理解，可能换一种说法更贴切：某些 App 逐步沉淀成为大而全的航母应用，而独立开发者做的 App 因为这些平台的存在而做得更加轻巧，功能更加单一。

这可能是超出了苹果和谷歌的意料之外的一种现象。这也是为什么大厂商要推动自己的混合应用框架，挟诸多开发者以令 OS 的原因吧？我个人还是认为手机 App 的初心还是在原生应用，但是我们必须混合多种开发技能，毕竟需求和应用场景各不相同。

InfoQ：您认为近几年移动架构设计思想有什么变化？在移动化浪潮中，客户端和服务端的边界在哪里，各自的架构设计应着重研究哪些方面？

肖恩：我能观察到的就是前端技术的渗入，原来只能应用到浏览器上的技术，现在纷纷出现在原生应用的开发阵营。另外一个就是后端一些模式和概念（或其变形）渗入到应用前端开发过程中。这种前端后端技术的互相渗透，一定程度上模糊了客户端和后端的技术边界。

我们还可以看到一些原本出现在服务端的 API 调用编排及数据格式转换等技术（参见淘宝的 TQL 及 Facebook 的 GraphQL），都纷纷出现在手机应用开发上。而移动化浪潮也是直接促进了通讯协议的升级，譬如千年不变的 HTTP 1.1 到 2.0 升级，这些在我看来都是很好的证据，说明前后端是互相交织促进、滚动发展的。

另外，随着终端和网络能力的提升，系统和中间件的成熟，移动架构设计走向了容器化、模块化、动态化。总结一下近几年客户端、服务端表现出的几个趋势：

1. 基础中间件走向成熟：网络加速、IM、Push、图片、数据统计、分享、社区、Crash 分析、安全加固等云端结合的基础服务提供方逐步集中到几个有实力的社区或企业中；
2. App 云端一体化：诸如 FireBase、LeanCloud、AWS Mobile Hub 的 MBaaS 架构极大地提升了端直接操纵云的能力，服务端和客户端的角色也发生了调整，服务端专注于提供稳定、可靠的基础服务以及基础服务端组合编排的能力，客户端更灵活的编排这些服务实现功能；
3. 动态化：除 H5 外，ReactNative 和 WeeX 的出现也提供了另一种动态化方式，客户端提供渲染引擎，服务端提供页面下发、更新、个性化的能力；
4. 个性化 (智能化)：客户端采集更丰富的数据，服务端依托大数据和算法提供更加个性和智能的服务。

InfoQ：移动端网络环境复杂（尤其在乡村下），在高峰期高流量的压力下还要保证流畅度，您认为在改善网络通道上有哪些事情可以做？

肖恩：网络通道的优化涉及了云、管、端。除满足性能外还需考虑体验、安全和容灾的要求。从客户端体验视角出发，移动端网络优化最有效的方式就是减少网络请求，例如客户端本地缓存 (图片)、使用 Push 机制替换 Pull 获取数据 (收藏夹、购物车) 都是经典且有效的方法。

对于必不可少的网络请求我们希望每个请求都尽可能快地响应，典型的网络请求包括：DNS、TCP 连接、安全通道建立、Request 发送、Response 接收，其中每个阶段都有值得优化的空间：

1. 使用自建的 HttpDNS 服务替换运营商 DNS 服务，DNS 异步化并把结果缓存在客户端，IP 直连服务端等方式，不仅可以把请求中 DNS 等待耗时降为 0，而且可以做到更加智能地调度，实现 IDC 按用户单元化部署、客户端就近就快接入、容灾快速切换；
2. 使用双工、多路复用的 TCP 长连接通讯协议 (如 SPDY、HTTP2)，不需要每次请求都建立 TCP 连接的同时，也对 Request、Response 的头和内容进行压缩；
3. 服务端 TCP 协议栈参数调优，优化慢启动和拥塞避免；
4. 安全通道选用内置证书和能够 0、1-RTT 完成握手的算法 (参考 TLS 1.3)，保障安全的同时能够极大地降低 TLS 握手时间；
5. 选用 Protobuf 等二进制协议减小传输数据大小，使用 ETag 和 304 减少不必要的 Response 传输。

基本上就这几个方面了，我们得针对各自场景，有选择性地进行调优。

InfoQ：不少企业兼顾开发 iOS 和 Android 应用，能否谈谈 iOS 和 Android 共同开发下有哪些降低各端开发成本的架构思路？

肖恩：设备碎片化颇令人头疼，尤其是 Android 设备的碎片化。我能想到的主要方式还是通过 iOS 和 Android 端统一架构、统一 UI、使用统一且成熟的基础中间件，尝试 ReactNative、WeeX 等混合跨端方案来降低适配难度。

底层基础组件可以使用 C/C++ 编写，非核心业务内容使用 H5 编写做到多端复用。同时在界面设计上尽可能避免不同设备的兼容问题；根据应用安装的分布情况，对产品设备的支持程度进行取舍来解决这类问题。

InfoQ：面对移动开发迅速更新换代，相关技术也越来越复杂，您认为技术负责人怎样才能做好移动客户端架构和技术选型，在这个过程中如何做好通盘考虑以及取舍和平衡？

肖恩：如果是小型团队，要快速地打造一个应用，我觉得怎么快怎么来就好。如果是中大型团队，并且要维持一个稳定的产品，那么还是要选择已经被证明的技术方案。如果团队能力允许的话，要尽可能地对要使用的新技术有一个充分的评估和了解，免费的东西最贵，开源的框架技术拿到手上最好还是多看一眼再用。

就个人偏好而言，我偏保守地稳妥发展。举例来说：我现在的主力笔记本还在用 Yosemite，等大家切换到了 Sierra 以后，我会开始升级到 El Capitan，另外一台测试机则利用开发者账号，第一时间升级最新的 OS 测试版本来体验把玩。

InfoQ：有人提过规模变大才是架构腐化的根源，您认可这个看法吗？能否结合服务治理谈谈有哪些措施和思想可以避免架构腐化？

肖恩：首先，我觉得这是个不容易直接得出结论的问题，且很容易引起争论。其次，我认为架构腐化是不可避免的，而规模变大可能会让架构腐败变得更快而已。

在没有服务治理概念的年代，依然可以找到设计良好的系统，而现在有了服务治理框架和工具，系统依然可能会腐化得很快。两者的关系就好比人的寿命长短和锻炼方式程度一样，其实并没有直接的联系。

记得我最初几年在做 Dubbo 时，参与过几个项目的服务化改造。当时的工作是通过梳理一个巨无霸应用的功能和范围边界，确定出一些核心的领域模型概念，基于这些概念，划分成子系统剥离出业务接口，然后利用 Dubbo 等 RPC 框架部署成独立的服务集群。因此这个阶段的服务治理，主要就是抽丝剥茧地分离大系统。

到了中后期，服务化被广泛使用后，我们就遇到了接口泛滥、版本控制、循环依赖等各种新的问题。

到了全民无线的时期，对服务化的新要求则是针对移动应用领域如何进行优化和支持了。

后来我在带领团队做一些重要的移动 App 的时候，因为多变的需求冲击，产品功能设计也不够充分，加上团队也比较稚嫩，所以那时候 App 的架构腐化得更快，到后来基本只能在原来代码上面堆砌功能，因为推倒重来的代价太大，因此非常痛苦。

结合我在两端开发不堪回首的经历，我认为：借助工具框架的力量，妥善做好应用功能分析分解，确保服务之间（或者应用内部功能模块之间）的模块化隔离解耦，也许能延缓一下架构腐化的速度。另外，团队的能力可能比这些方法论更重要。

InfoQ：感谢肖恩老师接受我们的采访，期待 ArchSummit 全球架构师峰会上您策划的日新月异的移动架构专题。

感谢夏雪对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们。