从0开始学架构
李运华
资深技术专家
立即订阅
38968 人已学习
课程目录
已完结 59 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 照着做,你也能成为架构师!
免费
基础架构 (13讲)
01 | 架构到底是指什么?
02 | 架构设计的历史背景
03 | 架构设计的目的
04 | 复杂度来源:高性能
05 | 复杂度来源:高可用
06 | 复杂度来源:可扩展性
07 | 复杂度来源:低成本、安全、规模
08 | 架构设计三原则
09 | 架构设计原则案例
10 | 架构设计流程:识别复杂度
11 | 架构设计流程:设计备选方案
12 | 架构设计流程:评估和选择备选方案
13 | 架构设计流程:详细方案设计
高性能架构模式 (8讲)
14 | 高性能数据库集群:读写分离
15 | 高性能数据库集群:分库分表
16 | 高性能NoSQL
17 | 高性能缓存架构
18 | 单服务器高性能模式:PPC与TPC
19 | 单服务器高性能模式:Reactor与Proactor
20 | 高性能负载均衡:分类及架构
21 | 高性能负载均衡:算法
高可用架构模式 (10讲)
22 | 想成为架构师,你必须知道CAP理论
23 | 想成为架构师,你必须掌握的CAP细节
24 | FMEA方法,排除架构可用性隐患的利器
25 | 高可用存储架构:双机架构
26 | 高可用存储架构:集群和分区
27 | 如何设计计算高可用架构?
28 | 业务高可用的保障:异地多活架构
29 | 异地多活设计4大技巧
30 | 异地多活设计4步走
31 | 如何应对接口级的故障?
可扩展架构模式 (6讲)
32 | 可扩展架构的基本思想和模式
33 | 传统的可扩展架构模式:分层架构和SOA
34 | 深入理解微服务架构:银弹 or 焦油坑?
35 | 微服务架构最佳实践 - 方法篇
36 | 微服务架构最佳实践 - 基础设施篇
37 | 微内核架构详解
架构实战 (13讲)
38 | 架构师应该如何判断技术演进的方向?
39 | 互联网技术演进的模式
40 | 互联网架构模板:“存储层”技术
41 | 互联网架构模板:“开发层”和“服务层”技术
42 | 互联网架构模板:“网络层”技术
43 | 互联网架构模板:“用户层”和“业务层”技术
44 | 互联网架构模板:“平台”技术
45 | 架构重构内功心法第一式:有的放矢
46 | 架构重构内功心法第二式:合纵连横
47 | 架构重构内功心法第三式:运筹帷幄
48 | 再谈开源项目:如何选择、使用以及二次开发?
49 | 谈谈App架构的演进
50 | 架构实战:架构设计文档模板
特别放送 (7讲)
架构专栏特别放送 | “华仔,放学别走!”第1期
架构专栏特别放送 | “华仔,放学别走!” 第2期
如何高效地学习开源项目 | “华仔,放学别走!” 第3期
架构师成长之路 | “华仔,放学别走!” 第4期
架构师必读书单 | “华仔,放学别走!” 第5期
新书首发 | 《从零开始学架构》
致「从0开始学架构」专栏订阅用户
结束语 (1讲)
结束语 | 坚持,成就你的技术梦想
从0开始学架构
登录|注册

49 | 谈谈App架构的演进

李运华 2018-08-18
专栏截止到上一期,架构设计相关的理念、技术、实践已经基本讲完,相信你一路学习过来会有一种感觉,这些内容主要都是讲后端系统的架构设计,例如存储高可用、微服务、异地多活等,都是后端系统才会涉及。事实上确实也是如此,通常情况下我们讲架构设计,主要聚焦在后端系统,但这并不意味着 App、前端就没有架构设计了,专栏所讲述的整套架构设计理念,虽然是来源于我的后端设计经验,但一旦形成完善的技术理论后,同样适应于 App 和前端。
首先,先来复习一下我的专栏所讲述的架构设计理念,可以提炼为下面几个关键点:
架构是系统的顶层结构。
架构设计的主要目的是为了解决软件系统复杂度带来的问题。
架构设计需要遵循三个主要原则:合适原则、简单原则、演化原则。
架构设计首先要掌握业界已经成熟的各种架构模式,然后再进行优化、调整、创新。
复习完我们就可以进入今天的正题,我来谈谈 App 架构的演进,以及上面这些架构设计关键点是如何体现的。

Web App

最早的 App 有很多采用这种架构,大多数尝试性的业务,一开始也是这样的架构。Web App 架构又叫包壳架构,简单来说就是在 Web 的业务上包装一个 App 的壳,业务逻辑完全还是 Web 实现,App 壳完成安装的功能,让用户看起来像是在使用 App,实际上和用浏览器访问 PC 网站没有太大差别。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学架构》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(24)

  • 李奋斗
    端上的技术,山上的天儿,都变得太快。端上的架构怎么演进?我觉得要把答案交给想象力,把时间尺度拉大看,想象力才是端上复杂度的主要来源,交互革命和场景升级是端技术栈发展的重要推动力。鼠标的发明,颠覆了命令行的交互思维,iphone的问世,分分钟让习惯了上屏下键的人们大开眼界,手机和网络的突进,解锁了一堆令人兴奋的场景。VR,混合现实,AI,5G等技术都可能极大推进端技术的变革,未来端架构怎么演进?不清楚,但有一点是清晰的,一大波复杂度,就在路上。

    作者回复: 学不动了😂😂😂

    2018-08-18
    1
    38
  • 江龙
    有个api的设计原则问题最近困扰好久,请教下,就是图中的首页其实有多个资源聚合,那是应该app端去请求多个资源服务,然后聚合出来展示;还是有个后台服务去聚合后端的各个基础服务,然后只提供一个接口给app访问?这其中的粒度如何把握?

    作者回复: 访问量大的,核心业务用服务器聚合,性能好;
    访问量小的,非核心业务用app聚合,可扩展性好;

    2018-09-03
    9
  • kyll
    其实,对于现在很多业务应用强制将用户绑到移动端很是反感。举个例子,第一次用丰巢寄件,竟然花了半小时,注册很麻烦。有些餐厅强制手机点餐,在pc端登录强制扫二维码,也很无语。多设备多渠道本质应该是为了方便快捷,随时随地享用服务。任何设备都有局限性,做好自己的本职即可。

    作者回复: 我也有点反感😊

    2018-08-18
    7
  • feifei
    我认为这个演讲也是朝着 all in one,即平台统一化,在app与原生接口间会出现统一化一个技术,类似java与jvm
    原因:
    1,原生开发成本高,每个平台都需要专门的开发人员
    2,手机性能的提高,能够为平台统一化提供条件
    3,用户体验,苹果的生态封闭,体验相对较好,但安卓平台很多公司都封装一套 导致体验差异很大

    作者回复: 英雄所见略同😄

    2018-08-20
    5
  • borefo
    一个系统架构设计出来后,如何预估这个系统能够支撑多大的请求量呢?

    作者回复: 不是先预估请求量,再设计架构么?

    2018-08-18
    3
  • 亚林
    前端技术茫茫多,所以我转后端了

    作者回复: 后端更多啊,😂😂

    2019-05-07
    2
  • Niuniu
    我的观点可能有点相反,但凡有人上来要做native app的时候,我一般都劝退不劝进。先仔细想想你需要的那些功能WebApp能不能实现,用户体验有没有差很多,没有的话,没必要做native app。能上webapp,先上webapp,人手不够时间紧,可以考虑hybrid,实在是非native app不可,才考虑写native的。

    作者回复: 赞同,新APP首要是快速验证业务,不是体验

    2019-01-16
    2
  • 天外来客
    未来app必然朝着更好的用户体验,更快的开发速度方向发展,考虑到Android和iOS都是基于Linux底层,可能会出现一个平台层隔离两者的差异,提供统一的移动端系统API供开发者使用,希望这一天早点到来

    作者回复: google Flutter已经在努力

    2018-09-29
    1
    2
  • Eric
    老师,我想问下 分布式 这种架构也算是面向服务做切分的一种架构模式嘛?我个人理解 分布式服务 有按功能分割的 ,也有按任务计算资源分割的,还是说 分布式 本身是一种扩展方案?我概念上有点乱,不知道老师怎么定义 分布式 这个概念,谢谢

    作者回复: 分布式是统称,泛指多台服务器联合起来完成业务功能,高性能,高可用,可扩展都可以用分布式架构

    2018-11-20
    1
  • killer
    各个平台的目标用户习惯本来就有差异。是个挑战
    2018-09-28
    1
  • 猿码架构
    未来提供平台化,屏蔽底层原生,正如pc端cs到bs的演进

    作者回复: 期待端出现一个JAVA,或者web一统天下,这样就不用两边甚至多平台重复开发

    2018-08-22
    1
  • 张玮(大圣)
    我的想法是:分久必合,合久必分

    就像移动端技术随业务的发展一样,不断变换,但最终还是因为某一个很痛的点回归原生,鸡汤下,也就是走在路上时间久了,注意看看来时的路,记得当初为什么出发?😄

    前几天在看graalvm,提供大一统平台,各种支持,如果单从技术角度来看,还是用最合适的技术解决合适的业务场景,合适的同时也成就了简单。

    短时间看,架构遵循华兄说的合适,简单
    长时间看,遵循演进原则。
    2018-08-19
    1
  • 刘祥
    公司进行技术委员会竞选,谈技术架构和人员培养认知,三页PPT阐述,有什么好的思路吗?
    2019-09-15
  • godtrue
    课后思考及问题
    你认为 App 架构接下来会如何演进?
    如果我能定,一定是大一统的方向,这样开发效率会多出不少。不过最终的方式应该和浏览器类似,有统一的标准,不过为了竞争优势,又会多做一些个性化的,就看谁能引领潮流成为事实的标志啦!最后可能是三国鼎立的局面。
    2019-09-04
  • 海罗沃德
    App最后还得是原生,开发多次就只能加人加钱,不然你不开发多次,同类型App发狠开发多次,竞争力就没有了,不过好的是,印度,澳洲,中国都可以接各种App的外包,作为甲方用心做好交互设计比什么都重要

    作者回复: 现在大趋势是前端开发业务,原生开发底层

    2019-07-29
  • Kliyes
    微信小程序一统江湖!

    作者回复: 不可能的

    2019-03-11
  • 大冯宇宙
    目前移动端的app大多数都在使用组件化的方式,主要目的还是针对业务的隔离,跟微服务的想法基本一样。但是随着5G的到来,我相信云上系统会更加发达,个人觉着未来有一天手机就相当于浏览器,完全从云上读取数据,甚至每一台手机都是一个移动云,这样每一个服务也会存在一个前端的模块,随取随用。
    2019-02-21
  • varotene
    没太理解前端组件化,容器化,能不能给点课外阅读或者再讲讲

    作者回复: 搜搜手淘Atlas框架

    2019-02-03
  • 波波安
    后面的趋势还是使用统一的架构,一次开发多个平台都能使用,在这个前提下不断优化体验。

    作者回复: 期望快点统一,学不动了😀

    2018-09-06
  • 文竹
    跨平台App仍是主要发展方向,此外一些跨平台的App快速设计产品也是主流(比如用Js编写,工具自动转换成原生APP)

    作者回复: React Native,weex,flutter

    2018-08-26
收起评论
24
返回
顶部