作者个人研发在高并发场景下提供了一个简单、稳定、可扩展的延迟消息队列框架，具有精准的定时任务和延迟队列处理功能。开源半年多以来，已成功为十几家中小企业提供精准定时调度解决方案，经受住了生产环境的考验。为了造福更多童鞋，这里提供一个开源框架地址：https://github.com/sunshinelyz/mykit-delay写的比较早随着互联网的发展，互联网公司的业务也在飞速发展，其中在反过来导致系统结构也在不断变化。总体来说，系统的架构大致经历了：单体应用架构->垂直应用架构->分布式架构->SOA架构->微服务架构的演进。当然，很多互联网公司的系统架构已经进化到ServiceMesh（面向服务的网格）。今天，我们就一起来聊聊系统架构的演进。单体应用架构在企业发展初期，一般公司的网站访问量都比较小。只需要一个应用程序，将所有功能代码打包成一个服务，部署在服务器上，支撑公司业务。这也降低了开发、部署和维护成本。比如大家熟悉的电子商务系统，主要包括：用户管理、商品管理、订单管理、支付管理、库存管理、物流管理等模块。前期我们会把所有的模块写成一个web项目，然后统一部署到一个web服务器上。这种架构特点有其优点：架构简单，项目开发和维护成本低。所有项目模块统一部署，便于小项目维护。但是它的缺点也很明显：所有的模块都是耦合在一起的，虽然对于小项目来说很容易维护。但是，对于大型项目，开发和维护并不容易。之前项目的模块太耦合了，如果一个模块出了问题，整个项目就没法用了。无法提高特定模块的性能。该项目不能水平缩放。正是因为单体式应用架构的诸多缺点，才逐渐演变为垂直应用架构。接下来，我们来看看垂直应用架构。垂直应用架构随着企业业务的不断发展，发现单节点的单体应用不足以支撑业务发展，因此企业会部署多个单体应用，并分别放置在不同的服务器上。但是这个时候会发现并不是所有的模块都会有比较大的访问量。如果想对项目中的某些模块进行优化和性能提升，此时对于单个应用是不可能的。于是乎，垂直应用架构诞生了。垂直应用架构就是把原来的项目应用拆分成几个互不相干的应用，从而提高系统的整体性能。这里，我们也以电子商务系统为例。在垂直应用架构下，我们可以将整个电子商务项目拆分为：电子商务交易系统、后台管理系统、CMS管理系统等。我们将单体应用架构拆分为垂直应用架构后，一旦访问量增加，我们只需要为访问量大的业务增加服务器节点，而不需要为整个项目增加服务器节点。这种架构的优点：系统是拆分的，可以根据不同系统的接入情况进行优化。水平扩展应用程序的能力。各系统共享整体访问流量，解决并发问题。如果一个系统发生故障，则不使用其他系统的运行条件，从而提高了整体容错率。这种架构的缺点：拆分出来的系统相对独立，不能相互调用。各个系统中难免会有重叠的服务，会出现服务的重复开发，给后期的维护增加了难度。分布式架构我们把系统演化成垂直应用架构后，当垂直应用越来越多的时候，重复写的业务代码也会越来越多。此时，我们需要将重复的代码抽象出来，形成一个统一的服务，供其他系统或业务模块调用。此时，系统将演化为分布式架构。在分布式架构中，我们将整个系统拆分为服务层和表现层。服务层封装了具体的业务逻辑供表现层调用，表现层负责处理与页面的交互。这种架构的优点：将重复的业务代码抽象出来，形成公共接入服务，提高代码复用性。系统和服务的性能优化可以有针对性地提升整体访问性能。这种架构的缺点：系统之间的耦合度变高，调用关系变复杂，难以维护。在SOA架构的分布式架构下，当部署的服务越来越多时，重复代码也会越来越多。对于容量评估，小服务资源浪费等问题较为严重。此时，我们需要增加一个统一的调度中心，对集群进行实时管理。此时，系统将演化为SOA（面向服务）架构。这种架构的优点：注册中心的使用解决了服务依赖和服务间调用关系的自动注册和发现。这种架构的缺点：服务之间存在依赖关系。如果某个服务出现故障，可能会造成服务的雪崩（关于穿透、击穿和雪崩，朋友们可以参考我之前一篇文章写的《【高并发】面试官：讲讲什么是缓存穿透?击穿?雪崩?如何解决?》）。服务之间的依赖和调用关系复杂，测试部署难度较大。微服务架构随着业务的发展，我们在SOA架构的基础上进一步扩展，将其完全拆分为微服务架构。在微服务架构下，我们将一个大项目拆分成可以独立部署的小微服务，每个微服务都有自己的数据库。这种架构的优点：服务完全拆分，每个服务独立打包、部署和升级。每个微服务负责的业务比较清晰，有利于后期的扩展和维护。REST和RPC协议可用于微服务之间的通信。这种架构的缺点：开发成本比较高。与每个服务相关的容错问题。涉及到数据一致性问题。本文转载自微信公众号“银禾科技”，可通过以下二维码关注。转载本文请联系冰川科技公众号。
