一、前言说到互联网系统架构，在互联网行业越来越成熟的今天，说到背后的技术体系，可能很多人从网上想到的，一张巨大的知识图谱，能把其中的一两个解释清楚的同学自然是胸怀大志，但对于新人来说，可能会直接被劝退。那么，我们是否需要学习并掌握所有这些相关技术呢？笔者认为，不必过分着急。需要明白的是，一个庞大复杂的互联网架构体系，必须有一个强大的团队共同支撑和维护。团队成员各司其职，各尽所能。这就是团队的力量。当然，相信很多人对于互联网系统架构的演进过程都有自己的理解，从单体应用到分布式应用，从开发框架到中间件技术，从容器化到云原生等等。但是，在这个复杂的技术体系中，从宏观的角度厘清其演进过程中的关键节点和可能存在的关键问题，对于我们理解一个大型互联网系统的架构是很有帮助的。2.大型互联网系统架构共同演进过程提示：系统架构应基于具体的业务场景。脱离具体业务谈技术架构难免像空中楼阁。关于系统架构的共同演进过程，网上相关文章数不胜数。不过，为了保持本文的整体完整性和连贯性，笔者认为还是有必要从基本的系统架构演进过程入手。对常见的大型互联网系统架构的演进过程有一个整体的概述，演进过程中的共性问题自然会得到解决。“一个优秀的大型互联网系统架构不是设计出来的，而是不断演进的。”我相信每个人都有类似的看法和思考，但为什么会这样呢？是技术同学技术能力不够，设计不出优秀的系统架构，还是技术同学写的bug太多，需要不断修复？笔者认为并非如此。架构演进的本质是技术服务于业务需求，而业务需求是不断变化和发展的，而这天生就注定了技术架构的不断演进，是必然的选择。正是因为随着业务的不断发展，用户数量不断增长，业务场景也越来越复杂。为了不断满足这些需求，对系统的要求自然会越来越高。因此，这是系统架构的不断发展。进化的根本原因。一般情况下，互联网系统技术架构的演进大致会经历以下几个阶段：在云服务日趋成熟的今天，笔者将对每个阶段的技术架构作如下简要说明：1.单-互联网业务开发中的节点架构在前期，通常会有一些试探性的产品探索/实验，而这些需求往往是请求者一时的想法/想法，被衍生和完善。它需要的是快速实现自己的想法，快速投入市场进行验证，然后不断收集市场反馈，完善整体的产品逻辑。因此，其典型特征是时效性要求高、产品逻辑不完善、不确定性大。这个阶段通常对技术架构要求不高，只需要实现基本的业务功能，技术投入自然不大。因此，单节点架构更合适。也就是说，所有的代码都写在一个项目里，应用、存储等服务部署在一台机器上。技术人员现阶段最重要的是保持良好的编程习惯，尽量为演进预留空间。当然，在云服务越来越成熟的今天，单节点架构通常如下图所示：即技术人员只需要在云服务器上部署自己的业务代码，数据直接存储在云端数据库，高效可靠。.（当然也可以直接在云服务器上自己搭建数据库存储，但是现在一般不会/不需要）2、随着业务的发展，集群架构也对集群架构提出了要求处理能力和系统的高可用性。随着要求越来越高，在单节点的基础上，集群架构应运而生。集群架构通常如下图所示：在集群架构阶段，会逐渐引入更多的技术/组件，团队成员也会逐渐壮大，这个阶段说明核心产品形态已经初步形成，并且有一定规模的相对稳定的流量。这时，技术团队开始面临挑战。现阶段技术团队最大的关键问题是规范制定/团队建设/人才储备。Tips：在云服务厂商的支持下，集群架构已经可以支撑大用户流量。云服务器、云数据库等基于云的基础服务的支撑能力也比往年好很多，升级扩容也方便很多，足以满足一般规模的系统性能需求。所以，不要认为业务量一上来就需要马上更改系统架构，因为这样可能会造成不必要的麻烦。有时，可以通过升级云服务器/云数据库等配置直接解决问题（一般来说，在正常的业务场景下，通过一些优化改造，能承受10000以下的QPS问题不大).3、分布式集群架构随着业务的进一步发展，系统流量越来越大，业务复杂度越来越高，需求迭代越来越频繁，技术团队成员也在快速发展（超过50人）。此时，团队协作、业务响应效率、系统“三高”等问题越来越突出，集群架构的短板也越来越明显。这时候，分布式集群架构的改造就需要提上日程了。分布式集群架构简图如下图所示：从集群架构演进到分布式集群架构，业务场景复杂度和技术复杂度都变得极高，复杂的业务/技术需求需要一个更专业的团队来处理整体协同支持。现阶段技术团队的重点问题是技术选型/团队协作/工具自动化/业务重构。（实际系统架构要复杂得多，这里只是简单举例说明）Tips：分布式集群架构改造时，需要合理梳理业务，划分服务，否则技术架构改造不仅不能解决实际问题，反而可能带来一系列的麻烦，真正成为“毒药”。4.未来架构未来的系统架构会往哪个方向发展？会是ServiceMesh方向，还是Serverless方向，还是其他方向？笔者也不好说，虽然这些技术架构方案在某些方面有一些优势，看起来设计理念确实不错，但是到目前为止，笔者并没有看到太多成功的大??型系统实施的。相关案例。因此，笔者在此不多说。不过笔者认为，有一个明显的趋势，就是云服务在未来的技术架构中将扮演越来越重要的角色。未来，对于绝大多数中小企业来说，技术架构的“云化”将是必然的选择；同时，随着云服务的日益完善，低代码也将成为解决实际业务问题的重要途径。的选择。Tips：微服务架构、容器化部署架构、SOA架构、混合云架构等，笔者认为，其实都可以看成是集群架构/分布式集群架构的扩展和变种。虽然具体的概念有些不同，但大体上，在相应的设计概念的边界上，基本没有颠覆性的区别。以上是对互联网系统架构演进过程的简要描述。作为一名技术人员，一般来说，大概率是不会把上面的过程完全走完的。他能亲身体验一个大型互联网系统架构从0到1的演进过程，很幸运。3.架构演进中不常讨论的一些问题。上面说的基本上很多书/教程都有详细的介绍。很少，一些问题与系统架构的演进有关。1、选择分布式集群架构的原因采用分布式集群架构（微服务）最关键的原因不仅仅是为了解决系统性能问题，很大一部分原因是为了解决业务迭代、团队协作、开发和调试，编译部署等问题。这是因为，随着系统业务复杂度的增加，团队成员的增加，对于单节点架构/集群架构，除了性能问题，业务耦合度高，逻辑不清，业务版本迭代不便，协同开发很容易。冲突、代码调试繁琐、部署风险高等相关问题将逐渐成为主要矛盾，而这些问题可以通过分布式架构的改造得到更好的解决。2、分布式集群架构改造的重点在技术架构演进过程中，绝非简单的扩容机器、拆解代码、划分服务。在不断演进的过程中，难点在于业务模型的完善设计流程重组，即业务架构。如果说在从单节点架构/集群架构过渡到分布式集群架构的过程中，我们只是选择了一个分布式服务框架，然后简单的把原来的代码结构拆分成服务包，然后通过框架调用它们.嗯，这绝不是完成了分布式架构的演进。现在社区已经有了一套比较成熟的分布式集群架构方案。在系统改造的过程中，分布式框架的选择和技术方案的制定已经不再是最难的问题。相对来说，在改造过程中，如何整体梳理现有业务逻辑，改造服务分工，是重点和难点，因为在这个阶段，通常面临着改造服务同时运行和服务分工的兼容性问题。在线服务，以及其他可能存在的沉重历史包袱。（这也是近年来DDD越来越流行的原因之一。）3.架构演进需要考虑的因素技术是为业务服务的，不能完全脱离业务来讨论技术架构。因此，在设计/选择技术架构时，需要充分结合实际业务场景进行取舍和平衡，避免盲目跟风、照搬别人的说法。再者，业务通常是基于一定的商业目的（不包括政府/非营利组织等），所以在做技术架构的时候，有时需要考虑商业因素。有时，甚至可能需要考虑政策/法律/语言和文化等因素。4.架构演进的终点技术架构是一个非常复杂的系统工程，从宏观的整体把握到基础代码实现，从服务端架构到客户端架构，从基础中间件到异构系统，无一不在这些，海阔天空，学无止境。我们只有站在前人的肩膀上，才不会太尴尬，要时刻保持敬畏之心。完成分布式集群架构的代码改造只是万里长征的第一步。后续，服务治理是分布式集群架构的重点和难点。可以说，只要业务场景需要，技术架构的演进就永无止境。5.架构演进的技术选择原则现在大部分的技术痛点，社区都有很多相关的解决方案。这时不要盲目应用。所有的篮子都被使用，导致了一个极其复杂的技术系统。开发/维护更复杂。需要注意的是，技术架构并不是越多越好，相反，越少越好，路要简单。应结合自身实际情况，如业务场景、团队整体技术栈、成员技术水平等，尽量选择通用且成熟的相关解决方案。我们不需要追求所谓的“前沿”，但还不够成熟。相关技术，简洁明了，往往是最合适的。6.架构演进的要点系统架构的演进过程实际上是一个不断权衡/平衡的过程。“三高”系统架构有三个常用轴（扩展、缓存、流控），技术架构演进到底。要真正落地，需要解决三个关键问题，即业务、技术和团队之间的平衡。业务是指实际的业务场景和业务迭代需求；技术是指技术选型和制定的技术方案；等），跨部门团队之间的沟通与协作。如果处理不好/协调好三者的关系，就会出现一个严重的问题，即技术方案已经制定/预研，但在实际推广实施时却难以推进，甚至由于长期无法推送，最终没有了。（在实际工作中，除了技术本身的问题，在技术架构实现的时候，人的问题往往更难处理。）7.架构演进中的安全问题在互联网技术架构的演进过程中，系统安全问题通常不会被优先考虑。这需要我们注意。应该说，造成这种情况的原因是多方面的。笔者认为，主要原因有以下几点：一是云服务厂商日趋完善。云服务使开发/部署基本且高度可靠的应用程序变得更加容易。更何况云服务厂商本身整体上做了很多基础安全工作，比如防火墙（硬件、软件）、风控识别、数据保护等。因此，相对于早期的自建机房/服务器托管方式，大大降低了系统层面的常规安全风险，即使出现相关风险，云服务商也会及时解决/协助解决。而这，在很大程度上，让我们往往对安全问题不敏感/关注。二是完善第三方基础服务商。一个系统涉及的关键业务流程中的支付（支付宝、微信等）、消息推送（短信、邮件等）、风险识别（色情、敏感信息等）都有成熟的服务商提供相关服务.通常情况下，您只需要接入相应的SDK，即可快速实现相关能力，简单高效。（第三方基础服务商一般都有比较成熟的安全/风控机制）三是社区开发框架的成熟和完善。在如今的互联网技术生态中，像Spring/Mybatis这样的开发框架已经越来越成熟稳定，几乎是行业标准的配置，而且得益于这些框架的完善，我们不再需要（或者只需要少量的配置）大部分可以处理/避免常见的安全问题。那么，我们真的可以无视安全问题吗？当然不是，因为诸如用户敏感数据保护、“羊毛党”问题等问题，我们时刻保持警惕，安全问题无处不在。说到底，在云服务商日趋成熟的今天，我们很幸运也很不幸……
