当前位置: 首页 > article >正文

从零开始学架构——互联网架构的演进

1 技术演进

1.1 技术演进的动力

  • 对于新技术,我们应该站在行业的角度上思考,哪些技术我们要采取,哪些技术我们不能用,投入成本过大会不会导致满盘皆输?
  • 市场、技术、管理三者组成的业务发展铁三角,任何一个不足都会导致企业的业务停滞不前,我们可以发现,其实三者都是服务于业务,业务有需求那么就应该尽量去满足,技术只不过是满足业务的一种手段
    可以将企业的业务分为:产品类、服务类
  • 产品类:开发出的产品,提供给用户使用,数据以及一些功能都可以定制化,且数据存储在用户本地
  • 服务类:更像是给你提供服务,所以需要将数据留在服务端,以便于更好的服务于用户
    • 服务的用户越多,价值也就越大
    • 服务类的业务符合互联网的特征和本质:“互联”+“网”

对于产品类业务,技术的创新会推动业务发展,比如UC浏览器独创云端架构,很好解决了上网满的问题等。
对于服务类业务,业务发展推动技术发展,可以发现和产品类业务相反

为什么业务发展是推动技术发展

  • 产品类更多的选择是个人喜好,因为产品一般提供的是功能,但是服务类的选择则是规模
    • 比如微信和qq你用哪个,如果社畜所在的公司都用的微信来进行沟通,那么你的人际关系可能就会转移到微信沟通上,qq就会逐渐舍弃,但是当规模都一样时,这时候可能才会看中个人喜好去选择

当规模成为业务的决定因素后,服务模式的创新就会成为业务发展的核心驱动力,而产品只是完成服务提供给用户使用的一个载体,服务类的业务发展路径一般是:一种创新的服务模式—>吸引了一批用户->业务开发发展->吸引更多用户->服务模式不断完善和创新->吸引更多用户

综上所述,除非是开创性的技术,能够推动活创造易总新的业务,其他情况下,都是业务的发展促使了技术的发展创新

1.2 淘宝发展

由于距离较多,以淘宝为例,讲述其发展,淘宝主要经历了 个人网站->Oracle/支付宝/旺旺->java时代1.0->java时代2.0->java时代3.0->分布式时代

1.2.1 个人网站

在淘宝初创时,并未考虑技术是否优越,也没有考虑性能是否海量,以及稳定,主要的考虑因素是快,快速上线

  • 当时的背景就是抢占先机,占领市场
  • 买一个系统就是为了快速可用,而买一个轻量级的系统就是为了“快速开发”
  • 业务决定技术,所以当时的架构也非常简单

1.2.1 Oracle/支付宝/旺旺

淘宝推出时,正好遇到非典,网购很火,且又采取了成功的市场运作,业务也发展起来,所以MySQL很快就撑不住了

  • 直接采取替换为Oracle,原因是容量大,稳定,安全,性能高,且有人员储备
  • 数据量变大后,本地存储又不够用,就买了NAS,加上Oracle RAC来实现负载均衡
  • 这个阶段主要就是买“性能”

1.2.3 Java时代1.0——脱胎换骨

这个阶段并没有直接去买技术,而是通过sun公司来转换开发语言为java,主要是因为,技术影响了业务的发展,频繁死锁和重启对用户业务产生了严重音响。

  • java时当时最成熟的网站开发语言,有良好的企业开发框架,被世界主流的大规模网站采用
  • 且java开发经验的人也多,后续维护成本低

1.2.4 Java时代2.0——坚若磐石

这个时期,淘宝做了很多优化工作:数据分库,放弃EJB,引入Spring,加入缓存,加入CDN,采用开源的JBoss

  • 这些操作都是围绕提高容量、提高性能、节约成本来做的,没有继续买技术来解决这些问题主要是买也解决不了问题,只能从架构上去优化
  • 买技术的成本会更高

1.2.5 Java时代3.0和分布式时代

这个阶段淘宝技术从商用转为“自研”,去IOE化

  • 这个阶段业务规模急剧上升后,复杂度高的IOE成本是这个阶段的主要原因

2 技术演进的模式

业务发展究竟是如何驱动技术发展的?

  • 业务模式虽然千差万别,但是无论什么样的业务,都需要有一定的技术同步发展进行支撑,因为业务的复杂性导致了,不得不去驱动技术
    • 因为面向的是服务,提供给用户的服务,就会有竞争,和安全保障
      • 你的服务不好,我就换一个好一点的呗
      • 你的服务导致我一个订单丢失几万几百,我难道还用你家服务啊
    • 用的人越来越多肯定会导致性能下降,功能越来越多也会导致架构变得复杂
  • 所以业务的复杂性要么来源于功能的不断叠加,和规模的扩大,从而对性能和可用性有了更高的要求。
    • 所以判断复杂性到底考虑功能复杂性,还是规模复杂性,还是都考虑
  • 应该基于业务的发展阶段来进行判断,不同的行业业务发展路径、轨迹、模式不一样、所以需要根据自身所在行业的发展以及自身情况进行判断
    假设是一个银行IT系统的架构师
  • 90年代的业务复杂度肯能就是业务范围扩大,功能增多和复杂,导致内部系统的数量增多,单系统功能越来越复杂
  • 2004年,转向网上银行,稳定性、安全性、易用性是主要复杂度,由IT系统自己解决
  • 2009年复杂度又转为移动支付,要应对其他第三方调用的请求,比如双十一,支付宝,微信等,高性能、稳定性、安全性是主要复杂度
    若假设你是淘宝的架构师:那么你会遇到的问题就会和银行IT遇到的问题不通,因为你们面向的业务不一样,所以复杂度出现的地方也可能不会相同,但是可能对于某一些相同的复杂度问题,也许有相似的解决方案

3 互联网业务发展

互联网业务千差万别,但由于其具有规模决定一切的相同点,发展路径也基本上是一致的
业务可以分为几个时期:初创期,快速发展期,竞争期,成熟期。
不同的时期的差别也主要体现在:复杂性、用户规模

3.1 业务复杂性

初创期
  • 这个时期的业务点在于创新,不是完善
  • 先创新吸引用户,所以要求就只有一个“快”
    • 同时初创时期,技术人员少,所以能买就买,能用开源的就用开源的
发展期
  • 当业务以及功能推出后,经过市场验证是可行的,那么吸引的用户就会越来越多
  • 此时的功能要求也会增加,所以快速实现需求是此阶段的核心任务
  • 如何做到快?
    • 堆功能:这时候就是朴实无华的增加功能,即使是重构,代码优化等想做可能都没有时间去做
    • 优化期:当发现新功能越来越难堆了,可能就是需要优化和重构代码的时候了,此时又会分为两派:优化派和架构派
  • 优化派:核心思想是将现有系统优化,比如重构代码,分层,优化SQL查询,硬件优化,数据库选型等等,就是对系统尽量小的改动,可以快速实施,但是这样做,可能撑不了多久
  • 架构派:调整系统架构,优化架构,将大系统拆分为多个相互配合的小系统,动作比较大,对业务的发展影响也很大
  • 大多数情况下,都是优化派能胜出
架构期
  • 很多情况下,业务量增长,即使进行了优化,慢慢也会发现扛不住,所以还是要进行架构优化
  • 总结一个字“拆”
    • 拆功能:将各个系统拆分为多个子系统
    • 拆分数据库:进行分库分表
    • 拆分服务器:根据子系统改成分布式或者集群,增加负载均衡系统
竞争期
  • 这个时候,由于市场已经形成,肯定会有人来分蛋糕,所以这个阶段对于技术的要求是更快了,也要有新的业务创新
  • 同时,架构优化后的美好时光就慢慢消逝,此时的问题体现如下
    • 重复造轮子:系统越来越多,相似的工作重复,例如每个系统都有存储,缓存等
    • 系统交互一团乱麻:各系统之间的交互变成了网状结构
  • 解决办法如下:
    • 平台化:用于解决重复造轮子的问题
      • 存储平台化:淘宝的TFS,京东的JFS
      • 数据库平台化:百度的DBProxy,淘宝的TDDL
      • 缓存平台化:Twitter的Twemproxy,腾讯的TTC
    • 服务化:系统之间交互混乱的问题,常见是通过MQ来完成系统间异步通知,或者使用服务框架
      • 消息队列:淘宝的Notify,MetaQ,Kafka等
      • 服务框架:Facebook的Thrift,淘宝的HSF等
成熟期
  • 此时企业已经熬过了竞争期,成为了行业的领头羊,业务已经趋于稳定和成熟,业务创新机会不多,更多是优化用户体验和项目求精方面,比如响应时间,以及用户体验,还有结构优化降低成本
  • 此时的优化可能就需要从各方面入手
    • 架构上的调整
    • 技术上的选型和采用可行成熟的新技术——需要测试
    • CDN、数据库、缓存、网络等
    • 机器硬件优化等等,没有规定死需要采用哪些优化

3.2 用户规模

用户量越来越大,导致对性能和可用性的要求越来越高

  • 性能:性能确实会随着用户规模变大而降低,原因是对于计算机来说,计算资源是有限的,过多的人导致了每个人能使用的资源变少,所以我们很多时候都是把资源变多来解决问题
    • 比如一台MySQL不够,我们可以多用几台,只不过就会设计到数据的同步等问题以及分库分表等问题
  • 可用性:可用性的关注点是系统故障出现的几率和持续时间
    • 如果系统宕机次数一天能达到2-3次,每次10分钟,肯定会影响用户操作,用户可能放弃产品的概率会很大
    • 同时也会影响收入,如果初创时期,人不多,可能最多损失几千,但是用户多起来后,损失可能就更大了

3.3 量变到质变

前面提到了复杂性和用户的规模是导致技术的发展,且不同的阶段带来的影响也是不同的,究竟用户规模发展到什么地步才会量变产生质变

阶段用户规模业务阶段技术影响
婴儿期0~1万初创期用户规模对性能和可用性都没有什么压力,技术人员可以安心睡好觉
幼儿期1~10万初创期用户规模对性能和可用性已经有一点压力了,主要体现为单台机器(服务器、数据库)可能已经撑不住了,需要开始考虑拆分机器,但这个时候拆分还比较简单,因为机器数量不会太多
少年期10~100万发展期用户规模对性能和可用性已经有较大压力了,除了拆分机器,已经开始需要将原来大一统的业务拆分为更多子业务了
青年期100~1000万竞争期用户规模对性能和可用性已经有很大压力了,集群、多机房等手段开始用上了虽然如此,技术人员还是很高兴的,毕竟到了此时公司已经发展得非常不错了
壮年期1000万~1亿竞争期&成熟期用户规模对性能和可用性已经有非常大压力了,可能原有的架构和方案已经难以继续扩展下去,需要推倒重来不过如果你真的身处这样一个公司,虽然可能有点辛苦,但肯定会充满干劲,因为这样的机会非常难得,也非常锻炼人
巨人气1亿+成熟期和壮年期类似,不过如果你真的身处这样一个公司,虽然可能有点辛苦,但估计做梦都要笑醒了!因为还没有哪个互联网行业能够同时容纳两家1亿+用户的公司
不管什么样的方式,核心都是满足业务快的要求,当发现业务快不起来的时候,其实就是技术的水平跟不上业务的发展,技术的变革和发展的时候就到了

4 总结

  • 产品类业务:技术创新推动业务发展。
  • “服务”类的业务:业务发展推动技术的发展。
  • 架构师需要基于业务发展阶段判断出系统当前面临的主要复杂度。
  • 互联网业务千差万别,但都具有“规模决定一切”的特点。
  • 互联网业务发展一般分为几个时期:初创期、快速发展期、竞争期、成熟期。
  • 互联网业务发展第一个主要方向就是“业务越来越复杂”。
  • 互联网业务发展第二个主要方向就是“用户量越来越大”。
  • 互联网业务发展带来复杂度的本质原因其实都是“量变带来质变”。

http://www.kler.cn/a/459423.html

相关文章:

  • 如何轻松关闭 iPhone 上的 HEIC [HEIC 图像技巧]
  • RocketMQ消费者如何消费消息以及ack
  • python +tkinter绘制彩虹和云朵
  • 计算机网络——期末复习(5)期末考试样例1(含答案)
  • 数据挖掘——关联规则挖掘
  • 25.1.3
  • C++ hashtable
  • No.3十六届蓝桥杯备战|数据类型长度|sizeof|typedef|练习(C++)
  • 线程-4-线程库与线程封装
  • 完整的 FFmpeg 命令使用教程
  • 【PyCharm】如何把本地整个项目同步到服务器?
  • 在web.xml中配置Servlet映射
  • 【Next.js】002-路由篇|App Router
  • 冒泡排序c语言
  • 百度PaddleSpeech识别大音频文件报错
  • vim/vi编辑器
  • 彩虹表的攻击与防御
  • 使用 IDE生成 Java Doc
  • C++基础:SGI STL二级空间配置器内存池
  • 【数据分析处理之缺失值】
  • Kafka消息不丢失与重复消费问题解决方案总结
  • 短视频矩阵系统搭建开发指导
  • 什么是模块?在Node.js中,每一个文件都被视为一个模块来处理
  • [Linux]从零开始的Nginx反向代理配置及运用教程
  • python3中条件判断语句:match...case语句
  • 后端Java开发如何向LLM方向转型