事件驱动运维自动化（事件驱动技术）

本篇文章给大家谈谈事件驱动运维自动化，以及事件驱动技术对应的知识点，希望对各位有所帮助，不要忘了收藏本站喔。 今天给各位分享事件驱动运维自动化的知识，其中也会对事件驱动技术进行解释，如果能碰巧解决你现在面临的问题，别忘了关注本站，现在开始吧！

本文目录一览：

• 1、程序员应知应会之自动化运维那些事儿
• 2、nodejs 还是python？
• 3、事件驱动微服务体系架构
• 4、大型互联网架构概述，看完文章又涨知识了
• 5、软件架构入门-分层架构、事件驱动、微服务架构和云原生架构

程序员应知应会之自动化运维那些事儿

对于一个开发人员来讲，可能运维并不是自己的职责所在。但是作为一名开发人员，却不能不了解自动化运维的整个流程。因为对于一个信息系统而言，开发和运维本质是一体的，尤其对于一些小公司来讲，可能运维人员本身就是开发人员抽空兼任的。

而自动化运维，本质上是介于开发和运维之间的，是运维和开发的交集，甚至很多时候都要写不少代码。因此，任何一个开发人员，都需要有自动化运维的相关知识。

一个了解好的开发人员，即使自己不做运维相关的工作，也能够知道自己在将项目交付给运维人员的时候，哪些东西是重要的，那些是必须配置的等等。然而在实际工作中，往往开发人员会给运维人员留下一些坑，一些只有他自己知道，而运维人员不知道的东西。导致运维人员自己试了很多次发现不行的时候，找到开发人员，开发人员研究了一下才会告诉他，在某某环境中必须用哪个端口之类的。这样不仅白白浪费了运维人员的时间，也增加了很多沟通的工作量。

反过来也是如此，一些现场的问题如果运维人员不能现场给出问题的定位。对于开发人员来讲是非常难以复现的。比如之前有某家企业，运维人员在客户现场发现问题。费了很大力气从客气的内网里面把日志导出来，发给开发人员，结果开发人员仔细研究了日志之后，发现是网不通的问题。开发人员显然是不可能知道为啥网不通的，搞不好是压根没连网线。

所以今天我们来聊一聊，对于一个程序员来讲，需要了解的自动化运维的那些事。

一、自动化运维的概念

随着信息时代的持续发展，初期的几台服务器已经发展成为了庞大的数据中心，单靠人工已经无法满足在技术、业务、管理等方面的要求。一个运维人员手工配置几台服务器还可能。配置几百上千台服务器那就累死了，还容易出错。那么就需要对运维工作进行标准化、自动化、架构优化、过程优化等。从面降低运维服务成本。其中，自动化最开始作为代替人工操作为出发点的诉求被广泛研究和应用。

所谓自 动化运维，即在最少的人工干预下，结合运用脚本与第三方工具，保证业务系统7*24小时高效稳定运行 。这是所有业务系统运维的终极目标。

按照运维的发展成熟度来看， 运维大致可分为三个阶段 ：

（1）依靠纯手工，重复地进行软件的部署与运维；

（2）通过编写脚本，方便地进行软件的部署与运维；

（3）借助第三方工具，高效地进行软件的部署与运维；

二、自动化运维需要解决的问题

自动化运维通常来讲，需要解决以下几个问题： 自动部署配置、风险事前预警、故障事中解决、和故障事后管理 。

三、自动化运维的常用工具

自动化运维常用的工具包括以下几种：

1、Ansible

ansible是基于Python开发的自动化运维工具，集合了众多运维工具（puppet、cfengine、chef、func、fabric）的优点，实现了批量系统配置、批量程序部署、批量运行命令等功能。

ansible具有如下一些特性：

(1)模块化：调用特定的模块，完成特殊的任务。

(2)Paramiko(python对ssh的实现)，PyYaml，jinja2(模块语言)三个关键模块。

(3)支持自定义模块，可使用任何编程语言写模块。

(4)基于python语言实现。

(5)部署简单，基于python和SSH(默认已安装)，agentless，无需代理不依赖KPI(无需SSL)。

(6)安全，基于OpenSSH

(7)幂等性：一个任务执行一次和执行n遍效果一样，不因重复执行带来意外情况。

(8)支持playbook编排任务，YAML格式，编排任务，支持丰富的数据结构。

(9)较强大的多层解决方案role。

2、Chef

Chef是一个功能强大的自动化工具，可以部署，修复和更新以及管理服务器和应用程序到任何环境。

Chef 主要分为三个部分 Chef Server、Workstation 以及 Chef Client。用户在 Workstation 上编写 Cookbook。然后，通过 knife 命令上传到 Chef Server。最后，在 Chef Client 上面实施安装和部署工作。所以，对于 Cookbook 地编写在整个自动化部署中起到了重要的作用。

Chef Server 包含所有配置数据，并存储描述Chef-Client中每个Nodes的Recipe，Cookbook和元数据。配置详细信息通过Chef-Client提供给Nodes。所做的任何更改都必须通过Chef Server进行部署。在推送更改之前，它通过使用授权密钥来验证Nodes和Workstations是否与服务器配对，然后允许Workstations和Nodes之间进行通信。

Workstations 用于与Chef-server进行交互，还用于与Chef-nodes进行交互。它还用于创建Cookbook。Workstations是所有交互发生的地方，在这里创建，测试和部署Cookbook，并在Workstations中测试代码。

Chef命令行工具 是创建，测试和部署Cookbook的地方，并通过此策略将其上载到Chef Server。

Knife 用于与ChefNodes进行交互。

Test Kitchen 用于验证Chef代码

Chef-Repo 是一个通过Chef命令行工具在其中创建，测试和维护Cookbook的存储库。

Nodes 由Chef管理，每个Nodes通过在其上安装Chef-Client进行配置。 ChefNodes 是一台机器，例如物理云，云主机等。

Chef-Client 负责注册和认证Nodes，构建Nodes对象以及配置Nodes。Chef-Client在每个Nodes上本地运行以配置该Nodes。

Cookbook 是Chef 框架的重要基础功能之一。在 Chef Server 对目标机器做安装部署的时候，是通过 Runlist。而 Runlist 里面又包含了一个一个具体的 Cookbook，所以，最终对一个目标机器的部署任务就落到了 Cookbook 上。而对于 Cookbook 来说，其中包含了多个组件，我们可以将 Cookbook 简单地理解成一个容器或者可以理解为一个包，里面包含了 recipes、files、templates、libraries、metadata 等信息。这些信息用于配置我们的目标机器。

3、Puppet

puppet是一种Linux、Unix平台的集中配置管理系统，所谓配置管理系统，就是管理其里面诸如文件、用户、进程、软件包等资源。它可以运行在一台服务器端，每个客户端通过SSL证书连接到服务端，得到本机器的配置列表，然后根据列表来完成配置工作，所以如果硬件性能比较高，维护管理上千上万台机器是非常轻松的，前提是客户端的配置、服务器路径、软件需要保持一致。

客户端Puppet会调用本地facter，facter探测出该主机的常用变量，例如主机名、内存大小、IP地址等。然后Puppetd把这些信息发送到Puppet服务端；

Puppet服务端检测到客户端的主机名，然后会检测manifest中对应的node配置，并对这段内容进行解析，facter发送过来的信息可以作为变量进行处理；

Puppet服务器匹配Puppet客户端相关联的代码才能进行解析，其他的代码不解析，解析分为几个过程，首先是语法检查，然后会生成一个中间的伪代码，之后再把伪代码发给Puppet客户端；

Puppet客户端接收到伪代码之后就会执行，执行完后会将执行的结果发送给Puppet服务器；

Puppet服务端再把客户端的执行结果写入日志。

4、Saltstack

SaltStack是基于python开发的一套C/S自动化运维工具。部署轻松，扩展性好，很容易管理上万台服务器，速度够快。与服务器之间的交流,以毫秒为单位。SaltStack提供了一个动态基础设施通信总线用于编排,远程执行、配置管理等等。它的底层使用ZeroMQ消息队列pub/sub方式通信，使用SSL证书签发的方式进行认证管理，传输采用AES加密。

在saltstack架构中服务器端叫Master，客户端叫Minion。

在Master和Minion端都是以守护进程的模式运行，一直监听配置文件里面定义的ret_port(接受minion请求)和publish_port(发布消息)的端口。当Minion运行时会自动连接到配置文件里面定义的Master地址ret_port端口进行连接认证。

saltstack除了传统的C/S架构外，其实还有一种叫做masterless的架构，其不需要单独安装一台 master 服务器，只需要在每台机器上安装 Minion端，然后采用本机只负责对本机的配置管理机制服务的模式。

saltstack提供如下一些功能：

（1）远程执行：（批量执行命令）在master上执行命令时，会在所有的minion上执行。

（2）配置管理/状态管理 ：（描述想到达到的状态，saltstack就会去执行）

（3）云管理(cloud)：用于管理云主机

（4）事件驱动：被动执行，当达到某个值会自动触发

这四种自动化运维工具的比较如下，现在主流的基本上ansible和saltstack用的多一些：

nodejs 还是python？

1.两者均能结束服务端的需求事件驱动运维自动化，不分伯仲。就像我们买车相同事件驱动运维自动化，买车的意图是为事件驱动运维自动化了出行，python和nodejs就像是路虎和群众，两者都是轿车，究竟谁的方位高?首要仍是看车主事件驱动运维自动化你的喜欢
了。相同，喜欢用python的人就会以为python方位高，擅长nodejs的人就会以为nodejs的方位高。但实际情况上时，截止现在两者均在服务端发挥着重要作用，并没有出现一个像轿车一个像自行车这
样的明显可比状况。
2.Node.js比较Python有以下利益。
快，nodejs比python快在了V8引擎和异步实行。Node.js根据V8引擎和异步网络和IOLibrary，和Python的Twisted很像，不同的是Node.js的eventloop是在很底层的，我们都知道越接近
底层功率越高。
其他npm作为Node.js的官方packagemanagement，汇集了整个社区最会集的资源;而Python却是easy_install和pip，还有python2和python3代码不通用的问题;
Windows支撑：Node.js有微软的支撑，在Windows上较安稳。libuv现已可以很好的兼容跨途径，Python尽管也对Windows有官方的支撑，但总时不时出些问题，例如在win10上的一些装置
包问题。

事件驱动微服务体系架构

如果您是一名企业架构师，您可能听说过微服务架构，并使用过它。虽然您过去可能使用REST作为服务通信层，但是越来越多的项目正在转向事件驱动的体系结构。让我们深入了解这种流行架构的优缺点、它所包含的一些关键设计选择以及常见的反模式。

什么是事件驱动的微服务体系结构?

在事件驱动的体系结构中，当服务执行其他服务可能感兴趣的某些工作时，该服务将生成一个事件—执行操作的记录。其他服务使用这些事件，以便它们能够执行由于该事件而需要的任何自己的任务。与REST不同，创建请求的服务不需要知道使用请求的服务的详细信息。

这里有一个简单的例子:当一个订单被放置在一个电子商务网站，一个单一的“订单放置”事件产生，然后被几个微服务消费:

1.order服务，它可以向数据库写入一个order记录。

2.客户服务，它可以创建客户记录。

3.支付服务，它可以处理支付。

事件可以以多种方式发布。例如，可以将它们发布到保证将事件交付给适当使用者的队列中，也可以将它们发布到发布事件并允许访问所有相关方的“发布/订阅”模型流中。在这两种情况下，生产者发布事件，消费者接收该事件，并做出相应的反应。注意，在某些情况下，这两个角色还可以称为发布者(生产者)和订阅者(消费者)。

为什么使用事件驱动的体系结构

与REST相比，事件驱动架构提供了以下几个优点:

异步——基于事件的架构是异步的，没有阻塞。这使得资源可以在他们的工作单元完成后自由地转移到下一个任务，而不用担心之前发生了什么或者接下来会发生什么。它们还允许对事件进行排队或缓冲，从而防止使用者向生产者施加压力或阻塞它们。

•松耦合——服务不需要(也不应该)知道或依赖于其他服务。在使用事件时，服务独立运行，不了解其他服务，包括其实现细节和传输协议。事件模型下的服务可以独立地、更容易地更新、测试和部署。

•易于扩展——由于服务在事件驱动的体系结构下解耦，而且服务通常只执行一项任务，因此跟踪特定服务的瓶颈，并对该服务(且仅对该服务)进行扩展变得很容易。

•恢复支持——带有队列的事件驱动架构可以通过“重播”过去的事件来恢复丢失的工作。当用户需要恢复时，这对于防止数据丢失非常有用。

当然，事件驱动的架构也有缺点。通过分离紧密耦合时可能更简单的关注点，它们很容易过度设计;它们可能需要大量的前期投资;而且常常导致基础设施、服务契约或模式、多语言构建系统和依赖关系图的额外复杂性。

也许最大的缺点和挑战是数据和事务管理。由于事件驱动模型的异步性，它们必须小心处理服务之间不一致的数据、不兼容的版本、监视重复的事件，并且通常不支持ACID事务，而不支持最终的一致性，因为后者更难以跟踪或调试。

即使有这些缺点，事件驱动的体系结构通常也是企业级微服务系统的更好选择。主要的优点是可伸缩的、松散耦合的、开发人员操作友好的。

何时使用REST

然而，有时REST/web接口可能仍然更可取:

•您需要一个异步请求/应答接口。

•您需要对强事务的支持。

•您的API对公众可用。

•您的项目很小(REST的设置和部署要简单得多)。

您最重要的设计选择—消息传递框架

一旦决定了事件驱动的体系结构，就该选择事件框架了。事件生成和使用的方式是系统中的一个关键因素。目前已有数十种经过验证的框架和选择，选择正确的框架需要时间和研究。

分俩个大类： 消息处理或流处理。

消息处理

在传统的消息处理中，组件创建消息，然后将其发送到特定的(通常是单个的)目的地。一直处于空闲状态并等待的接收组件接收消息并相应地执行操作。通常，当消息到达时，接收组件执行单个流程。然后，删除消息。

消息处理体系结构的一个典型例子是消息队列。尽管大多数较新的项目使用流处理(如下所述)，但是使用消息(或事件)队列的体系结构仍然很流行。消息队列通常使用代理的“存储和转发”系统，事件在此系统中从一个代理传递到另一个代理，直到它们到达适当的使用者。ActiveMQ和RabbitMQ是消息队列框架的两个流行示例。这些项目都有多年的实践经验和成熟的技术社区。

流处理

另一方面，在流内处理中，组件在达到某个状态时发出事件。其他感兴趣的组件在事件流中侦听这些事件并作出相应的反应。事件不针对特定的收件人，而是对所有感兴趣的组件可用。

在流内处理中，组件可以同时对多个事件作出反应，并对多个流和事件应用复杂的操作。有些流包括持久性，即事件在流上停留的时间可以根据需要延长。

通过流处理，系统可以重现事件的 历史 ，在事件发生后联机并仍然对其作出反应，甚至执行滑动窗口计算。例如，它可以从每秒的事件流计算每分钟的平均CPU使用量。

最流行的流处理框架之一是Apache Kafka。Kafka是许多项目使用的成熟和稳定的解决方案。它可以被认为是一种工业强度的流处理解决方案。Kafka有一个庞大的用户群、一个有用的社区和一个改进的工具集。

其他的选择

还有其他框架提供流和消息处理的组合，或者提供它们自己独特的解决方案。例如，Apache的最新产品Pulsar是一个开源的发布/订阅消息系统，它支持流和事件队列，所有这些都具有极高的性能。Pulsar的特点是丰富的-它提供多租户和地理复制-因此复杂。据说Kafka的目标是高吞吐量，而脉冲星的目标是低延迟。

NATS是另一种具有“合成”队列的发布/订阅消息系统。NATS是为发送小而频繁的信息而设计的。它提供了高性能和低延迟;然而，NATS认为某种程度的数据丢失是可以接受的，优先考虑性能而不是交付保证。

其他的设计考虑

一旦你选择了你的事件框架，这里有几个其他的挑战需要考虑:

•Event Sourcing

很难实现松耦合服务、不同的数据存储和原子事务的组合。一个可能有所帮助的模式是事件源。在事件源中，从来不直接对数据执行更新和删除;相反，实体的状态更改被保存为一系列事件。

•CQRS

上面的事件来源引入了另一个问题:由于需要从一系列事件构建状态，查询可能会很慢，而且很复杂。命令查询责任隔离(CQRS)是一种设计解决方案，它为插入操作和读取操作调用单独的模型。

•事件发现

事件驱动体系结构中最大的挑战之一是对服务和事件进行编目。在哪里可以找到事件描述和详细信息?事件发生的原因是什么?是哪个团队创造了这个活动?他们在积极地工作吗?

•应对变化

事件模式会改变吗?如何在不破坏其他服务的情况下更改事件模式?随着服务和事件数量的增长，如何回答这些问题变得至关重要。

成为一个好的事件消费者意味着要为变化的模式编码。成为一个好的事件生产者意味着要认识到模式更改如何影响其他服务，并创建经过良好设计的事件，这些事件被清楚地记录下来。

•内部部署vs.托管部署

无论您的事件框架是什么，您还需要在自行部署框架(消息代理的操作并不简单，特别是在高可用性的情况下)，还是使用托管服务(如Heroku上的Apache Kafka)之间做出选择。

反模式

与大多数体系结构一样，事件驱动的体系结构具有自己的一组反模式。以下是一些需要注意的地方:

设计过多的事件

注意不要对创建事件过于兴奋。创建太多的事件将在服务之间创建不必要的复杂性，增加开发人员的认知负担，增加部署和测试的难度，并导致事件使用者的拥塞。不是每个方法都需要是一个事件。

通用的事件

不要使用通用事件，无论是在名称中还是在目的上。您希望其他团队了解您的事件为何存在、应该用于什么以及应该在什么时候使用。事件应该有特定的目的，并相应地命名。事件与通用名称或通用事件与混乱的旗帜,导致问题。

复杂的依赖关系图

注意那些相互依赖的服务，并创建复杂的依赖关系图或反馈循环。每个网络跳都会给原始请求增加额外的延迟，特别是离开数据中心的南北网络流量。

这取决于保证的订单、交付或副作用

事件是异步的;因此，包含顺序或重复的假设不仅会增加复杂性，而且会抵消基于事件的体系结构的许多关键优点。如果使用者有副作用，例如在数据库中添加值，则可能无法通过重播事件进行恢复。

过早优化

大多数产品一开始很小，然后随着时间的推移而增长。虽然您可能梦想将来需要扩展到大型复杂组织，但是如果您的团队很小，那么事件驱动架构的额外复杂性实际上可能会降低您的速度。相反，考虑使用简单的体系结构来设计系统，但是要包含必要的关注点分离，以便您可以随着需求的增长将其替换掉。

期望事件驱动来修复所有问题

在较低的技术级别上，不要期望事件驱动的体系结构能够修复所有的问题。虽然这种体系结构肯定可以改进许多技术功能障碍的领域，但它不能解决核心问题，比如缺乏自动化测试、缺乏团队沟通或过时的开发-ops实践。

理解事件驱动架构的优缺点，以及它们最常见的一些设计决策和挑战，是创建尽可能好的设计的重要部分。

大型互联网架构概述，看完文章又涨知识了

1. 大型网站系统的特点

2. 大型网站架构演化历程

2.1. 初始阶段架构

问题事件驱动运维自动化：网站运营初期事件驱动运维自动化，访问用户少事件驱动运维自动化，一台服务器绰绰有余。

特征：应用程序、数据库、文件等所有的资源都在一台服务器上。

描述：通常服务器操作系统使用 linux，应用程序使用 PHP 开发，然后部署在 Apache 上，数据库使用 Mysql，通俗称为 LAMP。汇集各种免费开源软件以及一台廉价服务器就可以开始系统的发展之路了。

2.2. 应用服务和数据服务分离

问题：越来越多的用户访问导致性能越来越差，越来越多的数据导致存储空间不足，一台服务器已不足以支撑。

特征：应用服务器、数据库服务器、文件服务器分别独立部署。

描述：三台服务器对性能要求各不相同：应用服务器要处理大量业务逻辑，因此需要更快更强大的 CPU；数据库服务器需要快速磁盘检索和数据缓存，因此需要更快的硬盘和更大的内存；文件服务器需要存储大量文件，因此需要更大容量的硬盘。

2.3. 使用缓存改善性能

问题：随着用户逐渐增多，数据库压力太大导致访问延迟。

特征：由于网站访问和财富分配一样遵循二八定律：80% 的业务访问集中在 20% 的数据上。将数据库中访问较集中的少部分数据缓存在内存中，可以减少数据库的访问次数，降低数据库的访问压力。

描述：缓存分为两种：应用服务器上的本地缓存和分布式缓存服务器上的远程缓存，本地缓存访问速度更快，但缓存数据量有限，同时存在与应用程序争用内存的情况。分布式缓存可以采用集群方式，理论上可以做到不受内存容量限制的缓存服务。

2.4. 使用应用服务器集群

问题：使用缓存后，数据库访问压力得到有效缓解。但是单一应用服务器能够处理的请求连接有限，在访问高峰期，成为瓶颈。

特征：多台服务器通过负载均衡同时向外部提供服务，解决单一服务器处理能力和存储空间不足的问题。

描述：使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，提升系统的并发处理能力，使得服务器的负载压力不再成为整个系统的瓶颈。

2.5. 数据库读写分离

问题：网站使用缓存后，使绝大部分数据读操作访问都可以不通过数据库就能完成，但是仍有一部分读操作和全部的写操作需要访问数据库，在网站的用户达到一定规模后，数据库因为负载压力过高而成为网站的瓶颈。

特征：目前大部分的主流数据库都提供主从热备功能，通过配置两台数据库主从关系，可以将一台数据库服务器的数据更新同步到一台服务器上。网站利用数据库的主从热备功能，实现数据库读写分离，从而改善数据库负载压力。

描述：应用服务器在写操作的时候，访问主数据库，主数据库通过主从复制机制将数据更新同步到从数据库。这样当应用服务器在读操作的时候，访问从数据库获得数据。为了便于应用程序访问读写分离后的数据库，通常在应用服务器端使用专门的数据访问模块，使数据库读写分离的对应用透明。

2.6. 反向代理和 CDN 加速

问题：中国网络环境复杂，不同地区的用户访问网站时，速度差别也极大。

特征：采用 CDN 和反向代理加快系统的静态资源访问速度。

描述：CDN 和反向代理的基本原理都是缓存，区别在于 CDN 部署在网络提供商的机房，使用户在请求网站服务时，可以从距离自己最近的网络提供商机房获取数据；而反向代理则部署在网站的中心机房，当用户请求到达中心机房后，首先访问的服务器时反向代理服务器，如果反向代理服务器中缓存着用户请求的资源，就将其直接返回给用户。

2.7. 分布式文件系统和分布式数据库

问题：随着大型网站业务持续增长，数据库经过读写分离，从一台服务器拆分为两台服务器，依然不能满足需求。

特征：数据库采用分布式数据库，文件系统采用分布式文件系统。

描述：分布式数据库是数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用。不到不得已时，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。

2.8. 使用 NoSQL 和搜索引擎

问题：随着网站业务越来越复杂，对数据存储和检索的需求也越来越复杂。

特征：系统引入 NoSQL 数据库及搜索引擎。

描述：NoSQL 数据库及搜索引擎对可伸缩的分布式特性具有更好的支持。应用服务器通过统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。

2.9. 业务拆分

问题：大型网站的业务场景日益复杂，分为多个产品线。

特征：采用分而治之的手段将整个网站业务分成不同的产品线。系统上按照业务进行拆分改造，应用服务器按照业务区分进行分别部署。

描述：应用之间可以通过超链接建立关系，也可以通过消息队列进行数据分发，当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

纵向拆分：将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的 Web 应用系统。纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离即可。

横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务横向拆分需要识别可复用的业务，设计服务接口，规范服务依赖关系。

2.10. 分布式服务

问题：随着业务越拆越小，存储系统越来越庞大，应用系统整体复杂程度呈指数级上升，部署维护越来越困难。由于所有应用要和所有数据库系统连接，最终导致数据库连接资源不足，拒绝服务。

特征：公共业务提取出来，独立部署。由这些可复用的业务连接数据库，通过分布式服务提供共用业务服务。

3. 大型网站架构模式

3.1. 分层

大型网站架构中常采用分层结构，将软件系统分为应用层、服务层、数据层：

分层架构的约束：禁止跨层次的调用（应用层直接调用数据层）及逆向调用（数据层调用服务层，或者服务层调用应用层）。

分层结构内部还可以继续分层，如应用可以再细分为视图层和业务逻辑层；服务层也可以细分为数据接口层和逻辑处理层。

3.2. 分割

将不同的功能和服务分割开来，包装成高内聚低耦合的模块单元。这有助于软件的开发和维护，便于不同模块的分布式部署，提高网站的并发处理能力和功能扩展能力。

3.3. 分布式

大于大型网站，分层和分割的一个主要目的是为了切分后的模块便于分布式部署，即将不同模块部署在不同的服务器上，通过远程调用协同工作。

分布式意味可以用更多的机器工作，那么 CPU、内存、存储资源也就更丰富，能够处理的并发访问和数据量就越大，进而能够为更多的用户提供服务。

分布式也引入了一些问题：

常用的分布式方案：

3.4. 集群

集群即多台服务器部署相同应用构成一个集群，通过负载均衡设备共同对外提供服务。

集群需要具备伸缩性和故障转移机制：伸缩性是指可以根据用户访问量向集群添加或减少机器；故障转移是指，当某台机器出现故障时，负载均衡设备或失效转移机制将请求转发到集群中的其他机器上，从而不影响用户使用。

3.5. 缓存

缓存就是将数据存放在距离最近的位置以加快处理速度。缓存是改善软件性能的第一手段。

网站应用中，缓存除了可以加快数据访问速度以外，还可以减轻后端应用和数据存储的负载压力。

常见缓存手段：

使用缓存有两个前提：

3.6. 异步

软件发展的一个重要目标和驱动力是降低软件耦合性。事物之间直接关系越少，彼此影响就越小，也就更容易独立发展。

大型网站架构中，系统解耦的手段除了分层、分割、分布式等，还有一个重要手段——异步。

业务间的消息传递不是同步调用，而是将一个业务操作拆分成多阶段，每个阶段间通过共享数据的方式异步执行进行协作。

异步架构是典型的生产者消费模式，二者不存在直接调用。异步消息队列还有如下特性：

3.7. 冗余

大型网站，出现服务器宕机是必然事件。要保证部分服务器宕机的情况下网站依然可以继续服务，不丢失数据，就需要一定程度的服务器冗余运行，数据冗余备份。这样当某台服务器宕机是，可以将其上的服务和数据访问转移到其他机器上。

访问和负载很小的服务也必须部署 至少两台服务器构成一个集群，目的就是通过冗余实现服务高可用。数据除了定期备份，存档保存，实现 冷备份 外；为了保证在线业务高可用，还需要对数据库进行主从分离，实时同步实现 热备份。

为了抵御地震、海啸等不可抗因素导致的网站完全瘫痪，某些大型网站会对整个数据中心进行备份，全球范围内部署 灾备数据中心。网站程序和数据实时同步到多个灾备数据中心。

3.8. 自动化

大型网站架构的自动化架构设计主要集中在发布运维方面：

3.9. 安全

4. 大型网站核心架构要素

架构 的一种通俗说法是：最高层次的规划，难以改变的决定。

4.1. 性能

性能问题无处不在，所以网站性能优化手段也十分繁多：

4.2. 可用性

可用性指部分服务器出现故障时，还能否对用户提供服务

4.3. 伸缩性

衡量伸缩的标准就是是否可以用多台服务器构建集群，是否容易向集群中增删服务器节点。增删服务器节点后是否可以提供和之前无差别的服务。集群中可容纳的总服务器数是否有限制。

4.4. 扩展性

衡量扩展性的标准就是增加新的业务产品时，是否可以实现对现有产品透明无影响，不需要任何改动或很少改动，既有功能就可以上线新产品。主要手段有：事件驱动架构和分布式服务。

4.5. 安全性

安全性保护网站不受恶意攻击，保护网站重要数据不被窃取。

欢迎工作一到五年的Java工程师朋友们加入Java程序员开发： 721575865

群内提供免费的Java架构学习资料（里面有高可用、高并发、高性能及分布式、Jvm性能调优、Spring源码，MyBatis，Netty,Redis,Kafka,Mysql,Zookeeper,Tomcat,Docker,Dubbo,Nginx等多个知识点的架构资料）合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！

软件架构入门-分层架构、事件驱动、微服务架构和云原生架构

软件架构（software architecture）就是软件事件驱动运维自动化的基本结构。

合适的架构是软件成功的最重要因素之一。大型软件公司通常有专门的架构师职位（architect）事件驱动运维自动化，只有资深程序员才可以担任。

O'Reilly 出版过一本免费的小册子《Software Architecture Patterns》（PDF）事件驱动运维自动化， 介绍事件驱动运维自动化了五种最常见的软件架构，是非常好的入门读物。

软件架构就是软件的基本结构。架构的本质是管理复杂性。 如果事件驱动运维自动化你觉得架构不重要，可能是你做的事情不够复杂，或者是你没有管理好复杂性。架构模式虽多，经过抽象沉淀之后，也就那么几种：

1. 分层架构（比较传统的单体架构）

2. 事件驱动架构 （一般适用于应用局部场景，用来实现异步解耦）

3. 微核架构（又称插件架构，开发难度较高，一般用来做工具软件开发，如Eclipse，不太适合分布式业务场景）

4. 微服务架构（当前比较流行的服务化架构，解决单体架构面临的问题，适合敏捷开发，快速迭代）

5. 云架构（现在的说法是云原生架构-Cloud Native，基于Docker、Kubernetes、Service Mesh 云原生架构）

在原文的基础上，我按照自己的想法，进行了小幅调整。

分层架构（ layered architecture ）是最常见的软件架构，也是事实上的标准架构。如果你不知道要用什么架构，那就用它。

这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层之间通过接口通信。

虽然没有明确约定，软件一定要分成多少层，但是四层的结构最常见。

有的软件在逻辑层（business）和持久层（persistence）之间，加了一个服务层（service），提供不同业务逻辑需要的一些通用接口。

用户的请求将依次通过这四层的处理，不能跳过其中任何一层。

优点

缺点

事件（event）是状态发生变化时，软件发出的通知。

事件驱动架构（event-driven architecture）就是通过事件进行通信的软件架构。它分成四个部分。

事件驱动架构（event-driven architecture）核心组件：

对于简单的项目，事件队列、分发器和事件通道，可以合为一体，整个软件就分成事件代理和事件处理器两部分。

优点

缺点

事件驱动架构在通信产品中应用得也非常广泛，典型的如状态机处理。 事件驱动架构不适于做顶层架构，但适合做局部实现，几乎遍布在通信软件的各个角落。

微核架构（microkernel architecture）又称为"插件架构"（plug-in architecture），指的是软件的内核相对较小，主要功能和业务逻辑都通过插件实现。

内核（core）通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信，应该减少到最低，避免出现互相依赖的问题。

优点

缺点

微核架构的设计和开发难度较高，这就注定它在企业产品中用得不多，虽然它的优点还不少。

微服务架构（microservices architecture）是服务导向架构（service-oriented architecture，缩写 SOA）的升级。

每一个服务就是一个独立的部署单元（separately deployed unit）。这些单元都是分布式的，互相解耦，通过远程通信协议（比如REST、SOAP）联系。

微服务架构分成三种实现模式。

现在开源的微服务框架比较多，如常用的有Spring Cloud、Dubbo、ServiceComb等等。

优点

缺点

云架构（cloud architecture，现在的说法是云原生-Cloud Native）主要解决扩展性和并发的问题，是最容易扩展的架构。

它的高扩展性，主要原因是可以基于云上计算资源弹性伸缩。然后，业务处理能力封装成一个个处理单元（prcessing unit）。访问量增加，就新建处理单元（Docker容器）；访问量减少，就关闭处理单元（Docker容器）。由于没有中央数据库，所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都独立分库。

这个模式主要分成两部分：处理单元（processing unit）和虚拟中间件（virtualized middleware）。

虚拟中间件又包含四个组件：

随着Docker、Kubernetes等容器化技术的快速发展，上述关于云架构描述有点陈旧了。当前最新的云原生架构，以Docker+Kubernetes为核心，尤其是容器编排Kubernetes 已经成为事实上的行业标准。

云原生架构图的主要特征：

主要目标：

1. 让开发人员聚焦业务逻辑的实现，其他交给容器云平台来完成；

2. 支持业务系统的快速迭代，支撑业务的快速变化和发展；

3. 构建以共享服务体系为核心的业务中台；

下面是我针对某新零售企业设计的云原生架构图，以云和微服务架构为基础构建云原生应用，这里云可以是公有云、私有云、混合云等等。

以上是从不同的视角，对架构进行了分类。实际应用中，各种架构并不是孤立的，可以根据业务环境和业务诉求，对各种架构进行综合和嫁接。每种架构都有其优点和缺点。优点不必多说，缺点则几乎都是通过工具工程（比如自动化发布工具、自动化测试等等）能力的方法来规避，工具工程对软件架构非常重要。

关于事件驱动运维自动化和事件驱动技术的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 事件驱动运维自动化的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于事件驱动技术、事件驱动运维自动化的信息别忘了在本站进行查找喔。