从 0 开始学架构
李运华
网名“华仔”,前阿里资深技术专家(P9)
152573 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 66 讲
结束语 (1讲)
结课测试 (1讲)
从 0 开始学架构
15
15
1.0x
00:00/00:00
登录|注册

39 | 互联网技术演进的模式

服务框架
消息队列
缓存平台化
数据库平台化
存储平台化
拆服务器
拆数据库
拆功能
架构派
优化派
分布式存储
优化
求精
服务化
平台化
系统交互复杂
新系统增多
架构期
优化期
堆功能期
快速实现需求
用户反馈
快速迭代试错
业务创新
可用性要求
性能要求
成熟期
竞争期
发展期
初创期
技术变革和发展
量变到质变
用户规模
业务发展阶段
互联网技术演进的模式

该思维导图由 AI 生成,仅供参考

由于各行业的业务发展轨迹并不完全相同,无法给出一个统一的模板让所有的架构师拿来就套用,因此我以互联网的业务发展为案例,谈谈互联网技术演进的模式,其他行业可以参考分析方法对自己的行业进行分析。
互联网业务千差万别,但由于它们具有“规模决定一切”的相同点,其发展路径也基本上是一致的。互联网业务发展一般分为几个时期:初创期、发展期、竞争期、成熟期。
不同时期的差别主要体现在两个方面:复杂性、用户规模

业务复杂性

互联网业务发展第一个主要方向就是“业务越来越复杂”,我们来看看不同时期业务的复杂性的表现。
1. 初创期
互联网业务刚开始一般都是一个创新的业务点,这个业务点的重点不在于“完善”,而在于“创新”,只有创新才能吸引用户;而且因为其“新”的特点,其实一开始是不可能很完善的。只有随着越来越多的用户的使用,通过快速迭代试错、用户的反馈等手段,不断地在实践中去完善,才能继续创新。
初创期的业务对技术就一个要求:“快”,但这个时候却又是创业团队最弱小的时期,可能就几个技术人员,所以这个时候十八般武艺都需要用上:能买就买,有开源的就用开源的。
我还以淘宝和 QQ 为例。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

互联网业务发展的不同阶段呈现出不同的特点和挑战。初创期注重创新,发展期需快速满足不断增长的业务需求。随竞争加剧,业务变得更复杂,技术团队需应对系统数量激增和交互关系复杂化。成熟期则面临技术优化挑战。针对不同阶段提出解决方案,如平台化、服务化和技术优化策略。这些策略为读者提供了对互联网技术演进模式的深入理解,并可为其他行业的技术发展提供借鉴。文章简洁明了地阐述了互联网业务发展的技术特点和应对策略,对技术人员和企业管理者具有重要的参考价值。文章强调用户规模增大对技术的影响,包括性能和可用性要求的提升,以及量变带来质变的关系。最后,鼓励读者通过分析所在行业,寻找典型的技术演进模式。整体而言,本文深入浅出地探讨了互联网技术演进的基本模式,为读者提供了有益的思考和启发。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《从 0 开始学架构》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(33)

  • 最新
  • 精选
  • 孙振超
    在上一家公司经历了从发展期到竞争期的转变,起初业务增加比较快,各种功能不断向上堆。在后期开始慢慢搭建自己的文件存储系统、数据库中间件、消息中间件,当第一任架构师离职时cto的评价就是各种重构。 现在的公司应该算成熟期,虽然也面对着巨大的竞争压力,内部总结经历过几次大的架构阶段:第一代的大一统架构、第二代烟囱式架构、第三代分布式微服务架构、第四代的多地多中心架构以及现在正在进行的第五代架构升级。参与了多地多中心架构升级,也和腾讯的同学聊过,因而对异地多活有了一些定性认识,对于正在进行的第五代架构,还处于摸索阶段。

    作者回复: 你的经历非常有价值,好好总结一下,你也可以开专栏了😄

    2018-09-25
    4
    52
  • yoummg
    壮年期的公司,对于一个初级的工程师,应该在这样的公司做好什么事?

    作者回复: 在一个领域做精,成为专家

    2018-07-29
    23
  • 大兵
    不知道拼多多的架构演进是怎么样,在短短3年内发展到现在的规模?有在拼多多的同学吗?分享下

    作者回复: 应该很快就会在各种技术大会看到他们分享了

    2018-08-06
    2
    17
  • hello
    请教李老师,现在微服务架构已经很成熟了,特别是spring cloud 提供了各种基础服务,初创企业一开始就上微服务好像成本也不大,还需要经历从单体架构拆分的过程吗?

    作者回复: 可以用spring cloud ,但谨记我在微服务章节提到的三个火枪手原则,不要拆的太细

    2018-07-26
    3
    14
  • Bright.亮
    初创型公司,用户还不够一万,已经是分布式了,这样是不是有点儿浪费?

    作者回复: 看分布式的规模,如果只是简单拆几个服务是可以的,如果拆分成几十个微服务那就浪费了

    2018-07-29
    13
  • 大光头
    现在公司就处于竞争期,大家重复造轮子以及整合轮子的过程

    作者回复: 赶紧成立平台技术部,因为到了这个阶段,说明你们业务已经发展不错了,有资源投入

    2018-07-26
    2
    11
  • Kian.Lee
    公司应该属于“孕育期”,去年10月成立,业务类型 SaaS 服务产品,产品已成型,属于激进务实派,全面上云,后端 Spring boot + kotlin 部署 k8s + 公有云普惠型 DevOps,发布流水线,构建、测试、部署自动化,前端 Web VUE、SPA 无服务器部署(OSS),发布流水线,构建、测试、部署自动化,APP Weex+VUE 前端统一技术栈,监控 ARMS、流控 AHAS (代码无侵入),现在最幸福的事情,代码Push ,5分钟就能收到流水线部署成功通知。架构设计应该在“简单”、“适用”的原则上考虑适当的技术前瞻性!

    作者回复: WEEX还在维护么?😂

    2020-06-29
    2
    9
  • Amos
    看到华仔每条都有回复,真的很用心,虽然专栏已经结束了,依然向你学习。

    作者回复: 加油👍

    2018-09-20
    8
  • 日光倾城
    在一些小的互联网公司跳来跳去,当时都没想过公司处在什么阶段

    作者回复: 公司不同阶段对人要求不一样,机会也不一样

    2019-04-28
    5
  • 恒初
    作者能说说项目化运作的产品复杂度如果应对吗

    作者回复: 你是说类似2B类的产品么? 如果是外包类的一锤子买卖,基本不需要考虑演进,核心复杂度是如何用尽量少的人力和尽量低的成本来实现客户项目,这样利润才多。 如果是电信设备这类产品,后期的维护合同和升级合同比卖设备的钱还多,不过这种产品演进绝大部分是技术升级,而不是业务量和用户量增加。

    2021-03-17
    3
收起评论
显示
设置
留言
33
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部