大型互联网系统架构演进，BATJ其实无需神化……
d
老农小江约 10 分钟
老农小江约 10 分钟那么，我们是否需要对所有的这些相关技术，都全部学习掌握呢？笔者以为，大可不必过度焦虑，需要明白的是，一个庞大而复杂的互联网架构体系，必然是由一个强大的团队来共同支撑维护的，团队成员各司其职、各尽所长，而这也就是团队的力量。
当然，对于互联网系统架构的演进过程，相信很多人都有自己的理解，从单体应用到分布式应用、从开发框架到中间件技术、从容器化到云原生等等，不一而足。不过，在这庞杂的技术体系中，从宏观上理清其演变过程中的关键节点与可能面临的关键问题，对于我们理解一个大型互联网系统的架构，是很有裨益的。
系统架构应当是基于具体业务场景的，脱离了具体业务谈技术架构，难免有空中楼阁、镜花水月之嫌。系统架构常见的演变过程，网上的相关文章不胜枚举，不过，为了保持本文整体的完整性与连贯性，笔者以为，仍需从基本的系统架构演进过程说起，纲举则目张，先对常见大型互联网系统架构的演进过程有一个整体上的大致梳理，再说演进过程中常见的问题，也就水到渠成了。
“一个优秀的大型互联网系统架构，不是设计出来的，而是不断演进而来的” ，类似的观点，相信大家都有所了解，也有所思考，但是，为什么是这样的呢？是技术同学技术能力不够，设计不出优秀的系统架构吗，还是说技术同学写的BUG太多，需要不断修复？
笔者以为，都不是，架构的演变，其本质在于技术是服务于业务需求的，而业务需求是不断变化发展的，而这，天生就注定了技术架构的不断演变，是一种必然的选择。也正是因为随着业务的不断发展，用户体量不断增长，业务场景越来越复杂，为了不断满足这些需求，对系统的要求也就自然越来越高，所以，这才是系统架构不断演变的根本原因。
通常情况下，互联网系统技术架构的演变大致会经历以下几个阶段：
在云服务越来越成熟的今天，以下，笔者对各阶段的技术架构进行简单说明。
在这一阶段，对技术架构通常没有太高的要求，只需要实现基本的业务功能就行，从而技术投入自然也就不大，因此，单节点架构是比较适合的。即通常所说的，所有代码写在一个工程中，应用、存储等服务部署在一台机器上。技术人员在这一阶段最关键的在于保持良好的编程习惯、尽量预留演进余地。
当然，在云服务日渐成熟的今天，单节点架构通常如下图所示：
即，技术人员只需要将自己的业务代码部署在云服务器上，数据直接存储在云数据库中，高效且可靠性较高。（当然，也可以直接在云服务器上自己搭建数据库来存储，但现在一般不会/不需要这么做了）
在集群架构阶段，引入的技术/组件会慢慢变多，团队成员也会逐渐壮大，到了这一阶段，说明核心产品形态已初步成型，并已有相对稳定的、一定规模的流量，此时，技术团队开始迎来挑战。在这一阶段，技术团队最大的关键问题在于规范制定/团队建设/人才储备。
在云服务厂商的支持下，集群架构已经能够支撑较大的用户流量了。云服务器、云数据库等云端基础服务的支撑能力，也比前些年要好了很多，升级扩容也方便了许多，已经足够满足一般规模下的系统性能需求了。所以，不要觉得业务量一上来，就立马要改系统架构，因为这反而可能带来不必要的麻烦。有时，直接通过升级云服务器/云数据库等的配置，就可以解决问题了。（通常来说，常规业务场景下，通过一些优化改造，顶住1万以内的QPS是没有太大问题的）。
分布式集群架构简易示意如下图所示：
从集群架构演变到分布式集群架构，业务场景复杂度、技术复杂度都变得极高，繁杂的业务/技术需求，要求一个更专业的团队去整体协作支撑。在这一阶段，技术团队的关键问题在于技术选型/团队协作/工具化自动化/业务重构 。（实际系统架构情况要远远复杂得多，此处只是简单示意）
分布式集群架构改造过程中，需要对业务进行合理的梳理与服务划分，否则，技术架构的改造不但不能解决实际问题，反而可能带来一系列的麻烦，那就真的成了“毒药”了。
但是，笔者以为，有一点趋势还是比较明显的，那就是，云服务在未来技术架构中，将扮演越来越重要的角色。未来，对绝大多数中小企业来说，技术架构的"云化"将是必然的选择；与此同时，随着云服务的日益完善，低代码化也将成为一个重要的、解决实际业务问题的一种选择。
微服务架构、容器化部署架构、SOA架构、混合云架构等等，笔者以为，其实都可以看做是集群架构/分布式集群架构的延伸与变种，虽然具体概念上有些不同，但大体上来说，基本上在相应的设计理念边界上，并没有颠覆性的区别。
以上，就是对互联网系统架构演进过程的简单描述，作为一名技术人员，通常来说，大概率是不会完整经历以上过程的，能亲身经历一个大型互联网系统架构从0到1的演变过程，实属幸运。
以上所述，在不少书籍/教程中基本都有相关的详细描述，笔者就不再过多赘述了，此处笔者再说几点其它地方可能提的比较少的，关于系统架构演变相关的一些问题。
如果说，从单节点架构/集群架构过渡到分布式集群架构的过程中，只是选一个分布式服务框架，然后将原有代码结构进行简单拆分成各个服务包，再通过框架来进行调用，那么，这绝不算完成了分布式架构的演进。现如今，社区已有较为成熟的整套分布式集群架构解决方案，在系统改造过程中，分布式框架的选型与技术方案的制定，已不再是最困难的问题。相对而言，在改造过程中，如何对现有业务逻辑进行整体梳理与服务划分改造，才是重点与难点，因为在这一阶段，通常会面临改造服务与线上服务同时运行的兼容问题，以及其它可能存在的较为沉重的历史包袱。（这也是DDD最近几年日趋火热的原因之一吧）
业务，指的是实际业务场景与业务迭代诉求；技术，指的是技术选型与制定的技术方案；团队协作，指的是技术团队内部之间（基础架构团队、运维团队、业务开发团队等）、跨部门团队之间的沟通与协作。如果这三者之间的关系没有处理/协调好的话，就会出现一个严重的问题，那就是技术方案都制定/预研完成了，结果实际推广落地时，却很难推进，甚至因长时间推不动而最终不了了之。（实际工作中，技术架构的落地，除了技术本身的问题，人的问题往往更难搞）
1）云服务厂商的日趋完善
云服务使得开发/部署一个基本的、可靠性较高的应用较为简单，更进一步的是，云服务厂商本身，从整体上做了大量的安全方面的基础工作，如防火墙(硬件、软件)、风控识别、数据保护等等。因此，相对于早期的自建机房/服务器托管方式，系统层面的常规安全风险大大降低，即便出现相关风险的时候，云服务厂商也会及时解决/协助解决。而这，也在很大程度上让我们往往对安全问题不够敏感/重视。
2）第三方基础服务商的完善
一个系统所涉及的关键业务流程中的支付(支付宝、微信等)、消息推送(短信、邮件等)、风险识别(涉黄、敏感信息等)等等，都有成熟的服务商提供相关服务，通常只需要接入相应SDK即可快速实现相关能力，简便高效。（第三方基础服务供应商，一般都有一套相对成熟的安全/风控机制）
3）社区开发框架的成熟完善
在今天的互联网技术生态中，类似Spring/Mybatis之类的开发框架已越来越成熟稳定，几乎是行业标配，而得益于这些框架的完善，我们已不需要(或只需少量配置)就可处理/避免大多数常见的安全问题。
那么，我们是否真的可以忽略安全问题呢？当然不是，因为类似用户敏感数据保护问题、“羊毛党”问题等等、时刻警醒着我们，安全问题，无处不在。
工作在云服务厂商日渐成熟的今天，我们非常幸运，也非常不幸…...