文档阅读49|谈谈App架构的演进-极客时间专栏
发表时间：2023-10-23 20:03:34
文章来源：炫佑科技
浏览次数：153
菏泽炫佑科技
文档阅读49|谈谈App架构的演进-极客时间专栏
主要用于了解App架构的演进过程，比较前端架构和后端架构的区别和联系。
2.学习/操作
1. 文档阅读
49 | 49 聊聊App架构的演变——Geek Time
【转】Web研发模式的演变 - 于波 - 知乎
2. 组织输出 49 | 聊聊App架构的演变——Geek Time
截至本专栏上一期，架构设计相关的概念、技术和实践已经基本完成。 相信你在学习的过程中会有一种感受。 这些内容主要讲后端系统的架构设计，比如存储高可用、微服务等，服务、远程多活动等都涉及到后端系统。 事实上文档阅读49|谈谈App架构的演进-极客时间专栏，情况确实如此。 通常我们谈论架构设计时，主要关注后端系统，但这并不意味着App和前端没有架构设计。 虽然专栏中描述的整个架构设计理念都来自于我的后端设计经验，但一旦形成完整的技术理论，它也适用于App和前端。
首先我们回顾一下我专栏中描述的架构设计理念，可以细化为以下几个要点：
回顾完了，我们就可以进入今天的正题了。 下面我讲一下App架构的演变以及上述架构设计要点是如何体现的。
网页应用程序
很多*早的应用程序都采用了这种架构，大多数尝试性的业务一开始也有这种架构。 Web App架构也称为shell架构。 简单来说，就是将Web业务中的App包裹起来的一个外壳。 业务逻辑完全在Web中实现。 App shell完成安装功能，让用户看起来像是在使用App。 其实和使用浏览器访问PC网站没有太大区别。
为什么早期应用程序或新业务尝试采用这种架构？ 简单来说，是当时业务面临的复杂程度决定的。 我们以早期的Apps为例。 2010年前后，移动互联网虽然发展迅速，但受到用户设备、移动网络速度等制约。 PC互联网仍是主流，移动互联网仍是新生事物。 未来，其实大家可能无法完全看到当年的发展前景和趋势。 比如，淘宝2013年才决定“全线无线”，在这样的商业背景下，当时的业务重心还是在PC互联网上，移动互联网更具实验性。 既然是尝试，就要求速度快、成本低。 虽然当时苹果和iOS已经具备了开发App的功能，但原生开发成本太高。 因此，Web App的shell架构自然是大家尝试的首选。 架构上，主要解决“快速开发”和“低成本”两个复杂性问题。 架构设计遵循“适当性原则”和“简洁性原则”。
原生应用程序
虽然Web App解决了“快速开发”和“低成本”两个复杂性问题，但随着业务的发展，Web App的缺点逐渐成为主要的复杂性问题，主要体现在：
因此，随着业务的发展和技术的演进，移动开发的复杂性已经从“快速开发”、“低成本”转向“用户体验”。 为了保证用户体验，采用原生App架构是*合适的。 这里的建筑设计遵循“进化原则”。
原生应用解决用户体验问题。 如果我没记错的话，他们在2013年左右开始快速发展。那时候工程师、iOS工程师和现在的人工智能工程师一样受欢迎。 当时许多学生也从后端转行到应用程序。 发展。
应用程序
Apps很好地解决了用户体验问题，但业务和技术也在发展。 此时移动互联网已成为明显的大趋势。 团队需要考虑的不是是否要转移到移动互联网，而是如何在移动端使用。 互联网竞争日趋激烈，各种基于移动互联网特点的功能和体验方式不断被创造出来。 大家竞争的方式就是看谁能更快捕捉用户需求和痛点。 因此，移动开发的复杂性回归到了“快速开发”。 这个时候原生App开发的痛点就被发现了：因为iOS和Phone（你没看错，确实是当年这三个主流平台）的原生开发是完全不兼容的。 相同的功能需要在三个平台上重复开发。 每个平台都有一些差异，自然不会快。
为了解决“快速开发”的复杂度问题，大家很自然地想到了Web方式，但Web体验还是远不如原生。 如何解决这个问题呢？ 事实上，没有完美的解决方案，但您可以根据不同的业务需求选择不同的解决方案。 例如，体验要求高的业务可以使用原生App来实现，而体验要求低的业务可以使用Web来实现。 这就是App架构的核心设计。 其思路主要遵循建筑设计的“适宜原则”。
组件化和容器化
App可以更好地平衡“用户体验”和“快速开发”两个复杂性问题（注意是“平衡”，而不是“同时解决”），但对于一些超级App来说，随着业务规模变大，规模越来越大，业务变得越来越复杂。 虽然它在用户看来可能是一个App，但实际上承载着几十上百种业务。
以手机淘宝为例。 阿里巴巴确认“All in ”战略后，淘宝手机被定位为阿里巴巴集团移动端的“航母”，承载着众多子业务。 下图是淘宝首页的首屏，以及相关的子服务。 初步预计商家数量将超过10家。
再以微信为例，作为腾讯在移动互联网的“航母”，它也拥有很多服务。 如下图所示，“发现”标签页有7个子服务。
如此多的业务集中在一个App上，每一项业务都在不断扩展，未来可能会拓展新的业务，而且每一项业务都是由独立的团队开发，所以整个App的可扩展性引入了新的复杂性问题。
我在第32期专栏中提到，可扩展性的基本思想是“拆解”，但当这个思想应用到Apps和后端系统时，具体方法明显不同。 简单来说，App和后台系统有本质的区别。 App是面向用户的，而后台系统不是面向用户的。 因此，无论App如何拆解，仍然可以将同一个App呈现给用户。 将一个应用程序与另一个应用程序分开是不可能的。 该App被拆分为数十个独立的App； 后台系统不一样。 采用微服务架构后，后端系统可以毫无问题地拆分成数百或数千个子服务。 同时，无论App业务如何拆分，技术栈保持不变，否则无法整合为一个App； 但后端不同，可以使用不同的技术栈来开发不同的微服务。
在这种业务背景下，组件化和容器化架构应运而生。 基本思想是将超级App拆分成无数个组件。 这些组件遵循预先制定的规范，独立开发、独立测试、独立发布。 如果一个组件依赖于其他组件，则这些组件通过消息传递系统进行通信。 这样就实现了组件隔离，从而避免了各个团队之间的相互依赖和影响，从而提高了团队开发效率和整个系统的可扩展性。 。 组件化、容器化架构的出现遵循了架构设计的“进化原则”。 只有当业务复杂度发展到一定规模时才会适应。 因此，我们会看到更多的大公司应用这种架构，而中小型公司的应用业务并没有那么复杂，实际上也不一定需要采用组件化、容器化的架构。
组件化和容器化没有非常严格的定义。 我理解两者在规范、拆分、团队协作等方面都是一样的。 区别在于释放方式。 组件化采用静态发布，即所有组件都是独立的。 开发测试，然后以某个版本的App上线； 容器化采用动态发布，即容器可以动态加载组件。 当组件准备好后，就可以直接发布了。 容器会动态更新组件，无需等待某个版本上线。
更详细的手机淘宝App架构演进请参考微信App架构演进。
跨平台应用程序
前面介绍的各种App架构，除了Web App之外，都面临着同样的问题：跨平台需要重复开发。 如果相同的功能和业务开发过一次，iOS也必须重新开发。 这里其实存在一个人力投入的问题app开发，违反了建筑设计中的“简单原则”。 从企业的角度来看，我们当然希望减少人力投入成本（虽然从程序员的角度来看，我不希望程序员减少）。 因此，近年来，各种跨平台的解决方案不断涌现，并且较为知名。 有React、阿里巴巴的Weex等，虽然很多公司都在尝试使用，但目前这些解决方案还不是很成熟，用户体验与原生App还有一定的差距。 比如，他们宣布将放弃使用React，回归使用原生技术（ that they will放弃使用React， to using ——中国开源技术交流社区）。
前端的情况也类似。 有兴趣的同学可以看看于波的文章。 我不会在专栏中详细介绍。
概括
今天我就给大家讲讲App架构演变背后的原因和架构分析。 希望对您有所帮助。
这就是今天的全部内容。 我留给你一个问题。 您认为App架构下一步将如何发展？ 谈谈你的思考和分析。
欢迎您在留言区写下您的答案，与我讨论。 相信深入思考的答案也会让你对知识有更深刻的理解。 （小编插话：精彩留言就有机会获得丰厚福利！）
Web研发模式的演变——于波的文章
原始文章/博客不再可用
后续补充
...
3. 问题/补充
