讲架构设计主要聚焦在后端系统但这并不意味着 App、前端就没有架构设计了专栏所讲述的整套架构设计理念虽然是来源于我的后端设计经验但一旦形成完善的技术理论后同样适应于 App 和前端。架构设计理念可以提炼为下面几个关键点架构是系统的顶层结构。架构设计的主要目的是为了解决软件系统复杂度带来的问题。架构设计需要遵循三个主要原则合适原则、简单原则、演化原则。架构设计首先要掌握业界已经成熟的各种架构模式然后再进行优化、调整、创新。Web AppWeb App 架构又叫包壳架构简单来说就是在 Web 的业务上包装一个 App 的壳业务逻辑完全还是 Web 实现App 壳完成安装的功能让用户看起来像是在使用 App实际上和用浏览器访问 PC 网站没有太大差别。早期的 App 为例大约在 2010 年前后移动互联网虽然发展很迅速但受限于用户的设备、移动网络的速度等约束PC 互联网还是主流移动互联网还是一个新鲜事物未来的发展前景和发展趋势其实当年大家也不一定能完全看得清楚。例如淘宝也是在 2013 年才开始决定“All in 无线”的在这样的业务背景下当时的业务重心还是在 PC 互联网上移动互联网更多是尝试性的。既然是尝试那就要求快速和低成本虽然当时的 Android 和 iOS 已经都有了开发 App 的功能但原生的开发成本太高因此自然而然Web App 这种包壳架构就被大家作为首选尝试架构了其主要解决“快速开发”和“低成本”两个复杂度问题架构设计遵循“合适原则”和“简单原则”。原生 AppWeb App 虽然解决了“快速开发”和“低成本”两个复杂度问题但随着业务的发展 Web App 的劣势逐渐成为了主要的复杂度问题主要体现在移动设备的发展速度远远超过 Web 技术的发展速度因此 Web App 的体验相比原生 App 的体验差距越来越明显。移动互联网飞速发展趋势越来越明显App 承载的业务逻辑也越来越复杂进一步加剧了 Web App 的体验问题。移动设备在用户体验方面有很多优化和改进而 Web App 无法利用这些技术优势只有原生 App 才能够利用这些技术优势。因此随着业务发展和技术演进移动开发的复杂度从“快速开发”和“低成本”转向了“用户体验”而要保证用户体验采用原生 App 的架构是最合适的这里的架构设计遵循“演化原则”。原生 App 解决了用户体验问题没记错的话大约在 2013 年前后开始快速发展那个时候的 Android 工程师和 iOS 工程师就像现在的人工智能工程师一样非常抢手很多同学也是那时候从后端转行到 App 开发的。Hybrid App原生 App 很好的解决了用户体验问题但业务和技术也在发展移动互联网此时已经成为明确的大趋势团队需要考虑的不是要不要转移动互联网的问题而是要考虑如何在移动互联网更具竞争力的问题因此各种基于移动互联网特点的功能和体验方式不断被创造出来大家拼的竞争方式就是看谁更快抓住用户需求和痛点。因此移动开发的复杂度又回到了“快速开发”这时就发现了原生 App 开发的痛点由于 Android、iOS、Windows Phone(你没看错当年确实是这三个主流平台)的原生开发完全不能兼容同样的功能需要三个平台重复开发每个平台还有一些差异因此自然快不起来。为了解决“快速开发”的复杂度问题大家自然又想到了 Web 的方式但 Web 的体验还是远远不如原生怎么解决这个问题呢其实没有办法完美解决但可以根据不同的业务要求选取不同的方案例如对体验要求高的业务采用原生 App 实现对体验要求不高的可以采用 Web 的方式实现这就是 Hybrid App 架构的核心设计思想主要遵循架构设计的“合适原则”。组件化 容器化Hybrid App 能够较好的平衡“用户体验”和“快速开发”两个复杂度问题(注意是“平衡”不是“同时解决”)但对于一些超级 App 来说随着业务规模越来越大、业务越来越复杂虽然在用户看来可能是一个 App但事实上承载了几十上百个业务。可扩展的基本思想就是“拆”但是这个思想应用到 App 和后端系统时具体的做法就明显不同了。简单来说App 和后端系统存在一个本质的区别 App 是面向用户的后端系统是不面向用户的因此 App 再怎么拆对用户还是只能呈现同一个 App不可能将一个 App 拆分为几十个独立 App而后端系统就不一样了采用微服务架构后后端系统可以拆分为几百上千个子服务都没有问题。同时App 的业务再怎么拆分技术栈是一样的不然没法集成在一个 App 里面而后端就不同了不同的微服务可以用不同的技术栈开发。对于组件化和容器化并没有非常严格的定义我理解两者在规范、拆分、团队协作方面都是一样的区别在于发布方式组件化采用的是静态发布即所有的组件各自独自开发测试然后跟随 App 的某个版本统一上线容器化采用的是动态发布即容器可以动态加载组件组件准备好了直接发布容器会动态更新组件无需等待某个版本才能上线。跨平台 App除了 Web App 外其他都面临着同一个问题跨平台需要重复开发。同一个功能和业务Android 开发一遍iOS 也要开发一遍这里其实存在人力投入的问题违背了架构设计中的“简单原则”。站在企业的角度来讲当然希望能够减少人力投入成本(虽然我站在程序员的角度来讲是不希望程序员被减少的)因此最近几年各种跨平台方案不断涌现比较知名的有 Facebook 的 React Native、阿里的 Weex、 Google 的 Flutter。虽然也有很多公司在尝试使用但目前这几个方案都不算很成熟且在用户体验方面与原生 App 还是有一定差距例如 Airbnb 就宣布放弃使用 React Native回归使用原生技术( https://www.oschina.net/news/97276/airbnb sunsetting-react-native)。上一章: 开源项目如何选择、使用以及二次开发下一章: 架构实战架构设计文档归类: 从0开始学架构