架构杂谈——互联网系统架构演进

一、前言

说到互联网系统架构,在互联网行业日渐成熟的今天,一谈到这背后的技术体系,很多人脑海中可能就会浮现从网上看到的,一个个庞大的知识图谱,能说地清楚其中一二的同学,自然是志得意满,而对于新入行的同学来说,则可能直接就劝退了。

那么,我们是否需要对所有的这些相关技术,都全部学习掌握呢?

笔者以为,大可不必过渡焦虑,需要明白的是,一个庞大而复杂的互联网架构体系,必然是由一个强大的团队来共同支撑维护的,团队成员各司其职、各尽所长,而这也就是团队的力量。

当然,对于互联网系统架构的演进过程,相信很多人都有自己的理解,从单体应用到分布式应用、从开发框架到中间件技术、从容器化到云原生等等,不一而足。不过,在这庞杂的技术体系中,从宏观上理清其演变过程中的关键节点与可能面临的关键问题,对于我们理解一个大型互联网系统的架构,是很有裨益的。

二、大型互联网系统架构常见演变过程

Tips:
系统架构应当是基于具体业务场景的,脱离了具体业务谈技术架构,难免有空中楼阁、镜花水月之嫌。系统架构常见的演变过程,网上的相关文章不胜枚举,不过,为了保持本文整体的完整性与连惯性,笔者以为,仍需从基本的系统架构演进过程说起,纲举则目张,先对常见大型互联网系统架构的演进过程有一个整体上的大致梳理,再说演进过程中常见的问题,也就水到渠成了。

“一个优秀的大型互联网系统架构,不是设计出来的,而是不断演进而来的” ,类似的观点,相信大家都有所了解,也有所思考,但是,为什么是这样的呢?是技术同学技术能力不够,设计不出优秀的系统架构吗,还是说技术同学写的BUG太多,需要不断修复?

笔者以为,都不是,架构的演变,其本质在于技术是服务于业务需求的,而业务需求是不断变化发展的,而这,天生就注定了技术架构的不断演变,是一种必然的选择。也正是因为随着业务的不断发展,用户体量不断增长,业务场景越来越复杂,为了不断满足这些需求,对系统的要求也就自然越来越高,所以,这才是系统架构不断演变的根本原因。

通常情况下,互联网系统技术架构的演变大致会经历以下几个阶段:

在云服务越来越成熟的今天,以下,笔者对各阶段的技术架构进行简单说明:

1、单节点架构

在互联网业务发展的初期,通常是一些尝试性的产品探索/试验,而这些需求往往就是需求提出者的一个瞬间想法/点子,衍生完善而来。其需要的是快速实现其创意,并快速投放到市场验证,然后不断收集市场反馈,完善整体的产品逻辑,因此,其典型特点就是时效要求高、产品逻辑不够完善、不确定性大。

在这一阶段,对技术架构通常没有太高的要求,只需要实现基本的业务功能就行,从而技术投入自然也就不大,因此,单节点架构是比较适合的。即通常所说的,所有代码写在一个工程中,应用、存储等服务部署在一台机器上。技术人员在这一阶段最关键的在于保持良好的编程习惯、尽量预留演进余地。
当然,在云服务日渐成熟的今天,单节点架构通常如下图所示:

即,技术人员只需要将自己的业务代码部署在云服务器上,数据直接存储在云数据库中,高效且可靠性较高。(当然,也可以直接在云服务器上自己搭建数据库来存储,但现在一般不会/不需要这么做了)

2、集群架构
随着业务的发展,对系统的处理能力、高可用性也就提出了越来越高的要求,在单节点的基础上,集群架构应运而生,集群架构通常如下图所示:

在集群架构阶段,引入的技术/组件会慢慢变多,团队成员也会逐渐壮大,到了这一阶段,说明核心产品形态已初步成型,并已有相对稳定的、一定规模的流量,此时,技术团队开始迎来挑战。在这一阶段,技术团队最大的关键问题在于规范制定/团队建设/人才储备。

Tips:
在云服务厂商的支持下,集群架构已经能够支撑较大的用户流量了。云服务器、云数据库等云端基础服务的支撑能力,也比前些年要好了很多,升级扩容也方便了许多,已经足够满足一般规模下的系统性能需求了。所以,不要觉得业务量一上来,就立马要改系统架构,因为这反而可能带来不必要的麻烦。有时,直接通过升级云服务器/云数据库等的配置,就可以解决问题了。(通常来说,常规业务场景下,通过一些优化改造,顶住1万以内的QPS是没有太大问题的)。

3、分布式集群架构
随着业务的进一步发展,系统流量越来越大,业务复杂度越来越高,需求迭代越来越频繁,技术团队成员也快速发展(50人以上),此时,团队协作、业务响应效率、系统“三高”诉求等问题日益凸显,集群架构的不足之处日渐明显,此时,分布式集群架构的改造工作,也就需要开始提上日程了。

分布式集群架构简易示意如下图所示:

从集群架构演变到分布式集群架构,业务场景复杂度、技术复杂度都变地极高,繁杂的业务/技术需求,要求一个更专业的团队去整体协作支撑。在这一阶段,技术团队的关键问题在于技术选型/团队协作/工具化自动化/业务重构 。(实际系统架构情况要远远复杂得多,此处只是简单示意)

Tips:
分布式集群架构改造过程中,需要对业务进行合理的梳理与服务划分,否则,技术架构的改造不但不能解决实际问题,反而可能带来一系列的麻烦,那就真的成了“毒药”了。

4、未来架构
未来系统架构到底会往哪个方向发展,是往ServiceMesh方向发展,还是往Serverless方向发展,异或是别的方向?笔者也说不好,虽然这些技术架构方案都在某些方面体现了一些优越性,看起来设计理念确实很好,但是目前为止,笔者还没有看到太多成功落地实施的、较大规模系统的相关案例。所以,此处笔者也就不多妄言了。
但是,笔者以为,有一点趋势还是比较明显的,那就是,云服务在未来技术架构中,将扮演越来越重要的角色。未来,对绝大多数中小企业来说,技术架构的"云化"将是必然的选择;与此同时,随着云服务的日益完善,低代码化也将成为一个重要的、解决实际业务问题的一种选择。

Tips:
微服务架构、容器化部署架构、SOA架构、混合云架构等等,笔者以为,其实都可以看做是集群架构/分布式集群架构的延伸与变种,虽然具体概念上有些不同,但大体上来说,基本上在相应的设计理念边界上,并没有颠覆性的区别。

以上,就是对互联网系统架构演进过程的简单描述,作为一名技术人员,通常来说,大概率是不会完整经历以上过程的,能亲身经历一个大型互联网系统架构从0到1的演变过程,实属幸运。

三、架构演变不常说的一些问题

以上所述,在不少书籍/教程中基本都有相关的详细描述,笔者就不再过多赘述了,此处笔者再说几点其它地方可能提的比较少的,关于系统架构演变相关的一些问题。

1、选择分布式集群架构的原因

采用分布式集群架构(微服务),最关键的原因,不仅仅是为了解决系统性能问题,很大一部分原因,是为了解决业务迭代、团队协作、开发调试、编译部署等问题。这是因为,随着系统业务复杂度的提升、团队成员的增加,对单节点架构/集群架构来说,除了性能问题外,业务耦合度高且逻辑不清晰、业务版本迭代不便且协作开发易冲突、代码调试繁琐且部署风险大,等相关问题会逐渐变成主要矛盾,而通过分布式架构改造,就能较好地解决这些问题。

2、分布式集群架构改造的关键点

在技术架构演变的过程中,决不是简单粗暴地扩机器、拆代码、分服务,在不断演进过程中,难点其实在于对业务模型的完善设计,对业务流程的重新梳理,也就是业务架构。

如果说,从单节点架构/集群架构过渡到分布式集群架构的过程中,只是选一个分布式服务框架,然后将原有代码结构进行简单拆分成各个服务包,再通过框架来进行调用,那么,这决不算完成了分布式架构的演进。现如今,社区已有较为成熟的整套分布式集群架构解决方案,在系统改造过程中,分布式框架的选型与技术方案的制定,已不再是最困难的问题。相对而言,在改造过程中,如何对现有业务逻辑进行整体梳理与服务划分改造,才是重点与难点,因为在这一阶段,通常会面临改造服务与线上服务同时运行的兼容问题,以及其它可能存在的较为沉重的历史包袱。(这也是DDD最近几年日趋火热的原因之一吧)

3、架构演变需要考虑的因素

技术是服务于业务的,不能完全脱离于业务谈技术架构,所以,在进行技术架构设计/选型时,要充分结合实际业务场景进行取舍与平衡,切忌盲目随大流,人云亦云。更进一步,业务通常都是基于一定的商业目的的(政府/公益组织等不在其中),所以,在做技术架构时,商业因素有时也是需要考虑的。有时,甚至政策/法律/语言文化等因素,可能也需要有所考量。

4、架构演进的终点

技术架构是一个非常复杂的系统工程,从宏观上的整体把握到基本的代码实现,从服务端架构到客户端架构,从基础中间件到异构系统,凡此种种,浩如烟海,学无止境,我们只是站在前人的肩膀上,才不至于太过狼狈,要时刻心怀敬畏之心。分布式集群架构的代码改造完成只是万里长征的第一步,后续,服务治理才是分布式集群架构中的重点与难点。可以说,只要业务场景有需要,技术架构演进,永无止境。

5、架构演进技术选型的原则

现如今,大多数技术痛点,社区都有许多成套的相关解决方案,在这个时候,切忌盲目套用,一篮子全都使用了,造成整个技术体系异常庞杂,开发/维护都较为繁琐。需要注意的是,技术架构不是做的越多越好,相反,应当尽量少做,大道至简。我们应该结合自己的实际情况,如业务场景、团队整体技术栈、成员技术水平等综合考量,尽量选择通用的、成熟的相关解决方案就可以了,不需要追求所谓“前沿”但还不够成熟的相关技术,简洁而清晰的,往往是最适合的。

6、架构演进落地的关键点

系统架构的演进过程,其实就是一个不断取舍/平衡的过程,“三高”系统架构有常用的三板斧(扩容、缓存、流控),技术架构演变到最后,要实际落地的话,也会有三个关键问题需要处理,那就是业务、技术、团队协作之间这三者的平衡。

业务,指的是实际业务场景与业务迭代诉求;技术,指的是技术选型与制定的技术方案;团队协作,指的是技术团队内部之间(基础架构团队、运维团队、业务开发团队等)、跨部门团队之间的沟通与协作。如果这三者之间的关系没有处理/协调好的话,就会出现一个严重的问题,那就是技术方案都制定/预研完成了,结果实际推广落地时,却很难推进,甚至因长时间推不动而最终不了了之。(实际工作中,技术架构的落地,除了技术本身的问题,人的问题往往更难搞)

7、架构演进中的安全问题

在互联网技术架构的演进过程中,系统安全问题通常没有被重点考虑,这点需要引起我们的重视。造成这种情况,应该说有多方面的原因吧,笔者以为,主要原因有以下几个:
一是云服务厂商的日趋完善。云服务使得开发/部署一个基本的、可靠性较高的应用较为简单,更进一步的是,云服务厂商本身,从整体上做了大量的安全方面的基础工作,如防火墙(硬件、软件)、风控识别、数据保护等等。因此,相对于早期的自建机房/服务器托管方式,系统层面的常规安全风险大大降低,即便出现相关风险的时候,云服务厂商也会及时解决/协助解决。而这,也在很大程度上让我们往往对安全问题不够敏感/重视。

二是第三方基础服务商的完善。一个系统所涉及的关键业务流程中的支付(支付宝、微信等)、消息推送(短信、邮件等)、风险识别(涉黄、敏感信息等)等等,都有成熟的服务商提供相关服务,通常只需要接入相应SDK即可快速实现相关能力,简便高效。(第三方基础服务供应商,一般都有一套相对成熟的安全/风控机制)

三是社区开发框架的成熟完善。在今天的互联网技术生态中,类似Spring/Mybatis之类的开发框架已越来越成熟稳定,几乎是行业标配,而得益于这些框架的完善,我们已不需要(或只需少量配置)就可处理/避免大多数常见的安全问题。
那么,我们是否真的可以忽略安全问题呢?当然不是,因为类似用户敏感数据保护问题、“羊毛党”问题等等、时刻警醒者我们,安全问题,无处不在。

最后

工作在云服务厂商日渐成熟的今天,我们非常幸运,也非常不幸…

作者:Java架构师原文地址:https://segmentfault.com/a/1190000043380131

%s 个评论

要回复文章请先登录注册