自动化运维平台架构（自动化运维技术栈）

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

本文目录一览：

• 1、开发自动化运维架构六要素
• 2、如何基于Python构建一个可扩展的运维自动化平台
• 3、《Linux集群和自动化运维》pdf下载在线阅读全文，求百度网盘云资源
• 4、网络运维和网络安全有什么区别?
• 5、大型互联网架构概述，看完文章又涨知识了
• 6、什么是BSM、业务服务管理？

开发自动化运维架构六要素

运维自动化是我们所渴望获得的，但是我们在一味强调自动化能力时，却忽略了影响自动化落地的一个关键因素。那便是跟运维朝夕相处，让人又爱又恨的业务架构。
要点一：架构独立
任何架构的产生都是为了满足特定的业务诉求，如果我们在满足业务要求的同时，能够兼顾运维对架构管理的非功能性要求。那么我们有理由认为这样的架构是对运维友好的。
站在运维的角度，所诉求的架构独立包含四个方面：独立部署，独立测试，组件化和技术解耦。
独立部署
指的是一份源代码，可以按照便于运维的管理要求去部署、升级、伸缩等，可通过配置来区分地域分布。服务间相互调用通过接口请求实现，部署独立性也是运维独立性的前提。
独立测试
运维能够通过一些便捷的测试用例或者工具，验证该业务架构或服务的可用性。具备该能力的业务架构或服务让运维具备了独立上线的能力，而不需要每次发布或变更都需要开发或测试人员的参与。
组件规范
指的是在同一个公司内对相关的技术能有很好的框架支持，从而避免不同的开发团队使用不同的技术栈或者组件，造成公司内部的技术架构失控。
这种做法能够限制运维对象的无序增加，让运维对生产环境始终保持着掌控。同时也能够让运维保持更多的精力投入，来围绕着标准组件做更多的效率与质量的建设工作。
技术解耦
指的是降低服务和服务之间相互依赖的关系，也包含了降低代码对配置文件的依赖。这也是实现微服务的基础，实现独立部署、独立测试、组件化的基础。
要点二：部署友好
DevOps 中有大量的篇幅讲述持续交付的技术实践，希望从端到端打通开发、测试、运维的所有技术环节，以实现快速部署和交付价值的目标。可见，部署是运维日常工作很重要的组成部分，是属于计划内的工作，重复度高，必须提升效率。
实现高效可靠的部署能力，要做好全局规划，以保证部署以及运营阶段的全方位运维掌控。有五个纬度的内容是与部署友好相关的：
CMDB配置
在每次部署操作前，运维需要清晰的掌握该应用与架构、与业务的关系，为了更好的全局理解和评估工作量和潜在风险。
在织云自动化运维平台中，我们习惯于将业务关系、集群管理、运营状态、重要级别、架构层等配置信息作为运维的管理对象纳管于CMDB配置管理数据库中。这种管理办法的好处很明显，集中存储运维对象的配置信息，对日后涉及的运维操作、监控和告警等自动化能力建设，将提供大量的配置数据支撑和决策辅助的功效。
环境配置
在运维标准化程度不高的企业中，阻碍部署交付效率的原罪之一便是环境配置，这也是容器化技术主要希望解决的运维痛点之一。
腾讯的运维实践中，对开发、测试、生产三大主要环境的标准化管理，通过枚举纳管与环境相关的资源集合与运维操作，结合自动初始化工具以实现标准环境管理的落地。
依赖管理
解决应用软件对库、运营环境等依赖关系的管理。在织云实践经验中，我们利用包管理，将依赖的库文件或环境的配置，通过整体打包和前后置执行脚本的方案，解决应用软件在不同环境部署的难题。业界还有更轻量的容器化交付方法，也是不错的选择。
部署方式
持续交付原则提到要打造可靠可重复的交付流水线，对应用软件的部署操作，我们也强烈按此目标来规划。业界有很多案例可以参考，如Docker的Build、Ship、Run，如织云的通过配置描述、标准化流程的一键部署等等。
发布自测
发布自测包含两部分：
应用的轻量级测试；
发布/变更内容的校对。
建设这两种能力以应对不同的运维场景需求，如在增量发布时，使用发布内容的校对能力，运维人员可快速的获取变更文件md5，或对相关的进程和端口的配置信息进行检查比对，确保每次发布变更的可靠。
同理，轻量级测试则是满足发布时对服务可用性检测的需求，此步骤可以检测服务的连通性，也可以跑些主干的测试用例。
灰度上线
在《日常运维三十六计》中有这么一句话：对不可逆的删除或修改操作，尽量延迟或慢速执行。这便是灰度的思想，无论是从用户、时间、服务器等纬度的灰度上线，都是希望尽量降低上线操作的风险，业务架构支持灰度发布的能力，让应用部署过程的风险降低，对运维更友好。
要点三：可运维性
运维脑海中最理想的微服务架构，首当其冲的肯定是可运维性强的那类。不具可运维性的应用或架构，对运维团队带来的不仅仅是黑锅，还有对他们职业发展的深深的伤害，因为维护一个没有可运维性的架构，简直就是在浪费运维人员的生命。
可运维性按操作规范和管理规范可以被归纳为以下七点：
配置管理
在微服务架构管理中，我们提议将应用的二进制文件与配置分离管理，以便于实现独立部署的目的。
被分离出来的应用配置，有三种管理办法：
文件模式；
配置项模式；
分布式配置中心模式。
限于篇幅不就以上三种方式的优劣展开讨论。不同的企业可选用最适用的配置管理办法，关键是要求各业务使用一致的方案，运维便可以有针对性的建设工具和系统来做好配置管理。
版本管理
DevOps持续交付八大原则之一“把所有的东西都纳入版本控制”。就运维对象而言，想要管理好它，就必须能够清晰的描述它。
和源代码管理的要求类似，运维也需要对日常操作的对象，如包、配置、脚本等都进行脚本化管理，以备在运维系统在完成自动化操作时，能够准确无误的选定被操作的对象和版本。
标准操作
运维日常有大量重复度高的工作需要被执行，从精益思想的视角看，这里存在极大的浪费：学习成本、无价值操作、重复建设的脚本/工具、人肉执行的风险等等。
倘若能在企业内形成统一的运维操作规范，如文件传输、远程执行、应用启动停止等等操作都被规范化、集中化、一键化的操作，运维的效率和质量将得以极大的提升。
进程管理
包括应用安装路径、目录结构、规范进程名、规范端口号、启停方式、监控方案等等，被收纳在进程管理的范畴。做好进程管理的全局规划，能够极大的提升自动化运维程度，减少计划外任务的发生。
空间管理
做好磁盘空间使用的管理，是为了保证业务数据的有序存放，也是降低计划外任务发生的有效手段。
要求提前做好的规划：备份策略、存储方案、容量预警、清理策略等，辅以行之有效的工具，让这些任务不再困扰运维。
日志管理
日志规范的推行和贯彻需要研发密切配合，在实践中得出的经验，运维理想中的日志规范要包含这些要求：
业务数据与日志分离
日志与业务逻辑解耦
日志格式统一
返回码及注释清晰
可获取业务指标（请求量/成功率/延时）
定义关键事件
输出级别
管理方案（存放时长、压缩备份等）
当具体上述条件的日志规范得以落地，开发、运维和业务都能相应的获得较好的监控分析能力。
集中管控
运维的工作先天就容易被切割成不同的部分，发布变更、监控分析、故障处理、项目支持、多云管理等等，我们诉求一站式的运维管理平台，使得所有的工作信息能够衔接起来和传承经验，杜绝因为信息孤岛或人工传递信息而造成的运营风险，提升整体运维管控的效率和质量。
要点四：容错容灾
在腾讯技术运营（运维）的四大职责：质量、效率、成本、安全。质量是首要保障的阵地，转换成架构的视角，运维眼中理想的高可用架构架构设计应该包含以下几点：
负载均衡
无论是软件或硬件的负责均衡的方案，从运维的角度出发，我们总希望业务架构是无状态的，路由寻址是智能化的，集群容错是自动实现的。
在腾讯多年的路由软件实践中，软件的负载均衡方案被广泛应用，为业务架构实现高可用立下汗马功劳。
可调度性
在移动互联网盛行的年代，可调度性是容灾容错的一项极其重要的运维手段。在业务遭遇无法立刻解决的故障时，将用户或服务调离异常区域，是海量运营实践中屡试不爽的技巧，也是腾讯QQ和微信保障平台业务质量的核心运维能力之一。
结合域名、VIP、接入网关等技术，让架构支持调度的能力，丰富运维管理手段，有能力更从容的应对各种故障场景。
异地多活
异地多活是数据高可用的诉求，是可调度性的前提。针对不同的业务场景，技术实现的手段不限。
腾讯社交的实践可以参考周小军老师的文章“2亿QQ用户大调度背后的架构设计和高效运营”。
主从切换
在数据库的高可用方案中，主从切换是最常见的容灾容错方案。通过在业务逻辑中实现读写分离，再结合智能路由选择实现无人职守的主从切换自动化，无疑是架构设计对DBA最好的馈赠。
柔性可用
“先扛住再优化”是腾讯海量运营思想之一，也为我们在做业务架构的高可用设计点明了方向。
如何在业务量突增的情况下，最大程度的保障业务可用？是做架构规划和设计时不可回避的问题。巧妙的设置柔性开关，或者在架构中内置自动拒绝超额请求的逻辑，能够在关键时刻保证后端服务不雪崩，确保业务架构的高可用。
要点五：质量监控
保障和提高业务质量是运维努力追逐的目标，而监控能力是我们实现目标的重要技术手段。运维希望架构为质量监控提供便利和数据支持，要求实现以下几点：
指标度量
每个架构都必须能被指标度量，同时，我们希望的是最好只有唯一的指标度量。对于业务日趋完善的立体化监控，监控指标的数量随之会成倍增长。因此，架构的指标度量，我们希望的是最好只有唯一的指标度量。
基础监控
指的是网络、专线、主机、系统等低层次的指标能力，这类监控点大多属于非侵入式，很容易实现数据的采集。
在自动化运维能力健全的企业，基础监控产生的告警数据绝大部分会被收敛掉。同时，这部分监控数据将为高层次的业务监控提供数据支撑和决策依据，或者被包装成更贴近上层应用场景的业务监控数据使用，如容量、多维指标等。
组件监控
腾讯习惯把开发框架、路由服务、中间件等都统称为组件，这类监控介于基础监控和业务监控之间，运维常寄希望于在组件中内嵌监控逻辑，通过组件的推广，让组件监控的覆盖度提高，获取数据的成本属中等。如利用路由组件的监控，运维可以获得每个路由服务的请求量、延时等状态和质量指标。
业务监控
业务监控的实现方法分主动和被动的监控，即可侵入式实现，又能以旁路的方式达到目的。这类监控方案要求开发的配合，与编码和架构相关。
通常业务监控的指标都能归纳为请求量、成功率、延时3种指标。实现手段很多，有日志监控、流数据监控、波测等等，业务监控属于高层次的监控，往往能直接反馈业务问题，但倘若要深入分析出问题的根源，就必须结合必要的运维监控管理规范，如返回码定义、日志协议等。需要业务架构在设计时，前置考虑运维监控管理的诉求，全局规划好的范畴。
全链路监控
基础、组件、业务的监控手段更多的是聚焦于点的监控，在分布式架构的业务场景中，要做好监控，我们必须要考虑到服务请求链路的监控。
基于唯一的交易ID或RPC的调用关系，通过技术手段还原调用关系链，再通过模型或事件触发监控告警，来反馈服务链路的状态和质量。该监控手段属于监控的高阶应用，同样需要业务架构规划时做好前置规划和代码埋点。。
质量考核
任何监控能力的推进，质量的优化，都需要有管理的闭环，考核是一个不错的手段，从监控覆盖率、指标全面性、事件管理机制到报表考核打分，运维和开发可以携手打造一个持续反馈的质量管理闭环，让业务架构能够不断进化提升。
要点六：性能成本
在腾讯，所有的技术运营人员都肩负着一个重要的职能，就是要确保业务运营成本的合理。为此，我们必须对应用吞吐性能、业务容量规划和运营成本都要有相应的管理办法。
吞吐性能
DevOps持续交付方法论中，在测试阶段进行的非功能需求测试，其中很重要一点便是对架构吞吐性能的压测，并以此确保应用上线后业务容量的健康。
在腾讯的实践中，不仅限于测试阶段会做性能压测，我们会结合路由组件的功能，对业务模块、业务SET进行真实请求的压测，以此建立业务容量模型的基准。也从侧面提供数据论证该业务架构的吞吐性能是否达到成本考核的要求，利用不同业务间性能数据的对比，来推动架构性能的不断提高。
容量规划
英文capacity一词可以翻译成：应用性能、服务容量、业务总请求量，运维的容量规划是指在应用性能达标的前提下，基于业务总请求量的合理的服务容量规划。
运营成本
减少运营成本，是为公司减少现金流的投入，对企业的价值丝毫不弱于质量与效率的提升。
腾讯以社交、UGC、云计算、游戏、视频等富媒体业务为主，每年消耗在带宽、设备等运营成本的金额十分巨大。运维想要优化运营成本，常常会涉及到产品功能和业务架构的优化。因此，运维理想的业务架构设计需要有足够的成本意识，
小结
本文纯属个人以运维视角整理的对微服务架构设计的一些愚见，要实现运维价值最大化，要确保业务质量、效率、成本的全面提高，业务架构这块硬骨头是不得不啃的。
运维人需要有架构意识，能站在不同角度对业务架构提出建议或需求，这也是DevOps 精神所提倡的，开发和运维联手，持续优化出最好的业务架构。

如何基于Python构建一个可扩展的运维自动化平台

Django- 一个开放源代码的 Web 应用框架，由 Python 写成，采用了 MVC 的软件设计模式；
rpyc- 一个 Python 实现的 RPC 和分布式计算的工具。支持同步和异步操作、回调等；
saltstack 、 ansible 、 func - 基本 Python 开发的自动化配置管理与流程控制组件；
Mysql- 是一个非常流行的关系型数据库管理系统。
二、平台架构设计
1、 OMServer 架构图
大家对这个架构应该不会感到陌生，三层结构也是目前主流的运营平台架构。
2、 架构说明
OMServer 平台为三层架构，分别为 WEB 交互层、分布式计算层、集群管理服务层。
1） 、第一层：即为 WEB 交互层，典型的 B/S 架构，以供管理员操作的交互平台，也是 OMServer 的核心，基于 Django 开发；
2） 、第二层：分布式计算层，提供与主控端的连接通道，采用的是 rpyc 传输协议，协议操作流程：前端模块参数 - 加密传输 - 任务执行 - 返回结果集 - 解密输出。
3） 、第三层：集群管理服务层，整合 Python 主流的远程操作组件（支持 Saltstack 、 Anaible、 Func ），对被控端（业务服务器集群）进行管理，其中主控端可以根据不同 IDC 环境，采用多地多点的管理方式，可提升冗余度及执行效率。主控端操作模块以不同 Python 文件加以区分，便于维护，可灵活定制操作逻辑及横向扩展等特点。

《Linux集群和自动化运维》pdf下载在线阅读全文，求百度网盘云资源

《Linux集群和自动化运维》（余洪春）电子书网盘下载免费在线阅读

链接：https://pan.baidu.com/s/1JXwxgIg-e2b2kaxm6A0hSQ

提取码：HURK  

书名 ：Linux集群和自动化运维

豆瓣评分：6.7

作者: 余洪春

出版社：机械工业出版社

出版年: 2014-9

页数: 401

内容简介：

《高性能Linux服务器构建实战：系统安全、故障排查、自动化运维与集群架构》是Linux运维领域畅销的、公认的经典著作《高性能Linux服务器构建实战：运维监控、性能调优与集群应用》的姊妹篇，它从系统安全运维、运维故障排查、自动化运维、集群架构4个维度讲解了构建大规模和高性能Linux服务器集群所需要的技术、工具、方法和技巧，二者一脉相承，互为补充，内容涵盖了运维工程师构建高性能服务器需要掌握的各种知识。本书在内容上继承了前面一本书中被读者认可的诸多优点：实用（以实际生产环境为背景）、实战（包含大量案例）、易懂，同时也改进了读者反馈的不足之处。

全书共14章，分为四个部分：安全运维篇（1-3章）主要讲解了服务器安全运维、网络安全运维和数据安全运维的关键技术和方法；运维故障排查篇（4-5章）从服务器系统和应用软件两个维度讲解了运维故障的排查思路，以及常见的和经典的运维故障的解决方案；自动化运维篇（6-9章）主要讲解了海量主机的自动化部署和配置、自动化监控、分布式监控等大规模集群运维所需的各种工具（pssh、pdsh、mussh、Ganglia、nagios、Centreon等）和方法；集群架构篇（10-14）讲解了如何构建和优化基于Web和MySQL数据库的高性能集群和高可用的负载均衡集群。

作者简介 ：

高俊峰（南非蚂蚁），资深运维专家、系统架构师、DBA和技术顾问，从事Linux/Unix服务器系统的架构、运维和管理多年。擅长大规模服务器集群的运维和管理，在故障诊断与排除、自动化运维、安全运维、性能调优、虚拟化等方面积累了大量的实战经验。国内知名IT技术社区51CTO的博客专家和ChinaUnix论坛高可用集群版块的版主，同时还活跃于ITPUB等技术社区，在社区和论坛里发表了大量技术文章，深受欢迎。此外，他还著有畅销书《循序渐进Linux》和《高性能Linux服务器构建实战：运维监控、性能调优与集群应用》，后者是本书的姊妹篇，是Linux运维领域公认的经典著作。

网络运维和网络安全有什么区别?

运维，主要工作是管理和维护，建设公司业务基础架构的职业，包含服务器，中间价，数据库，各类集群建设，架构优化等工作，当然也需要一些基础网络知识和安全架构知识融合在工作里。
网络安全，包含网络通信安全和应用安全，主要是根据业务需求或基础架构设计或者加固安全防范措施及方案。
网络安全和运维理论上是两个不同工种，但是实际工作是中相辅相成的，缺一不可。

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

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等多个知识点的架构资料）合理利用自己每一分每一秒的时间来学习提升自己，不要再用"没有时间“来掩饰自己思想上的懒惰！趁年轻，使劲拼，给未来的自己一个交代！

什么是BSM、业务服务管理？

Mocha BSM是摩卡软件有限公司自动化运维平台架构的5大产品之一。
什么是Mocha BSM 4+1
Mocha BSM 4+1是由以下组成自动化运维平台架构：
1 – 基础架构管理
企业自动化运维平台架构的IT基础架构系统包括了网络设备自动化运维平台架构，网络拓扑，主机，主机可视化以及IT资产，Mocha BSM的基础架构管理对这些不同IT系统的关键成分提供了监控与管理。
2 – 应用管理
应用管理对以下几个重要的应用分类进行了监控与管理：
·J2EE应用服务器
·Lotus Domino
·Portal
·数据库与LDAP
·Web Server
·URL Ports
·Mail
3 – 响应时间管理
通过Mocha BSM对以下进行监控与管理：
录制与模拟用户使用网站的关键操作与步骤，并且可以定时回放，并且监控用户在这些页面的响应时间与HTTP状态。
对一个复杂的业务系统，比如网站包括了Web Server，应用服务器和数据库，能够监控各个子系统的响应时间，如果网站出现慢的现象，就能定位是那一个子系统出现问题。
4 – 业务服务管理
以服务的视角来管理企业的IT系统，提供了以下功能：
可视化服务定义 - 服务是由网络，主机与应用组成的，能够通过可视化方式把这些不同的系统组成一个服务。
服务仪表盘 - 让业务部门和IT部门领导了解提供给他们的服务状况而不是技术细节，通过仪表盘展现服务状况以及KPI。
+
1 – IT流程管理
通过IT流程管理，以ITIL的流程框架，缔造一个自动化和规范化的IT运维系统
Back to top
Mocha BSM4+1为客户带来了什么？
基础架构管理，提高高可用性，让业务系统可持续运行
企业的各种IT设备，种类繁多，包括主机、路由器、交换机以及成百上千的员工终端，共同构成了企业的神经网络，为企业的正常运营，提供强大的基础设施支撑。
Mocha BSM 4+1的基础架构管理包括：
网络设备和网络拓扑管理
通过SNMP的主动查询方式，全面监控网络设备运行状况，自动发现企业的网络拓扑。
主机监控，包括对Unix，Linux，Windows主机
以Agent和Agentless两种监控方式，对不同操作系统下面的主机进行监控。
主机可视化管理
以实时动态的展现界面，达到直观的监控主机系统，并可以直接对关键进程进行操控，降低技术门槛。
IT资产管理
通过自动发现IT资产，实现了企业IT资产的全生命周期的管理。
第三方监控软件的数据和事件整合
可以无缝整合IBM，HP，BMC等第三方监控软件。
应用管理，为企业核心应用提供保障
自动化运维平台架构我们支持对所有主流应用监控，并提供可视化地展现企业应用系统的部署架构，帮助IT管理者能够从复杂的应用系统管理中释放出来，一目了然地了解应用的状态。一旦应用组件出现问题，Mocha BSM能够帮助管理者快速定位出应用系统的根本原因，并快速予以恢复，尽最大可能的帮助企业挽回损失。
Mocha BSM支持的应用监控包括：
对各种不同的应用服务提供监控与管理，主要包括：
·J2EE应用服务器
·Lotus Domino， WebSphere， Weblogic， SunOne等
·对Web服务的监控，主要包括：Apache，IIS
·对数据库和LDAP服务的监控：主要包括：SQL Server， DB2，Oracle
·对邮件服务器，主要包括：Lotus Mail，MS Exchange等
响应时间管理，掌握用户体验，提高用户满意度
针对复杂和跨不同应用平台的业务系统（比如一个网站包括了Web Server，应用服务器，数据库等系统），我们提供各应用环节或子系统的响应时间监控，帮助IT管理员获取在各个应用阶段的事务反应时间，从而找出整个应用服务的瓶颈；
现在企业拥有很多的Web应用，但是IT部门往往不知道用户体验，而只是通过监控软件提供可用性和性能指标，但是最关键的用户体验被忽略。企业应用最重要的用户-企业领导往往因为IT系统响应速度慢，浪费了宝贵时间。现在，通过Mocha RTM Studio，我们可以达到以下：
·录制这些用户的体验
·定时模拟这些用户体验，确保响应时间实在可接受范围内，如果不是，第一时间通知IT管理员
通过响应时间管理，IT部门不只是能找到业务系统的瓶颈，并且能通过掌握用户体验，大大提高了用户（特别是领导）的满意度，而网站企业能避免没必要客户的流失，因为竞争只是“一点击”之远。
业务服务管理，让IT服务可视化和量化
Mocha BSM帮助IT管理员从服务的视角来管理IT系统，而不是底层的技术组件。这让IT管理员从业务部门的视角出发，理解业务部门是以提供给他们的服务质量为至关重要，而不是具体的技术细节。当故障发生时，IT管理员也能快速定位受影响的用户，并且第一时间通知他，并让他理解故障对服务的影响。
现在，IT部门领导能通过业务服务的视角，建立全局意识，通过KPI报表和图表，进行长期规划和决策，确保IT基础架构即使经历较大的风险，也能快速恢复，维持IT部门的可持续性管理。
SLM（服务水平管理）将IT服务进行量化，业务部门通过SLA规定的各项服务承诺进行对照，从而了解IT服务的质量以及SLA的满足情况，IT部门的工作范畴也有了量化的目标，并向着SLA所制定的方向迈进。
IT流程管理，以ITIL为核心，迈向规范化，自动化和流程化的IT运维平台。
以ITIL推动规范化和流程化
Mocha BSM 4+1是以ITIL流程框架为核心，遵循并实现了服务支持（Service Support）与服务提供（Service Delivery）。流程是ITIL的核心，通过Mocha BSM 4+1，客户可以通过灵活配置IT流程和表单，实现了IT运维所需要的流程管理。
自动化运维平台
Mocha BSM 把事件和IT流程关联起来，形成了IT自动化必备的工单。一旦被监控系统发生性能超标或者宕机，Mocha BSM会触发相关事件以及事先定义好的流程，可以自动恢复系统。
IT管理员也能用这个自动化运维平台达到：
·自动系统健康检查
·自动配置变更提醒
·自动生成运维周报
......
等多种自动化功能，大大提高了IT管理员的工作效率。
Back to top
Mocha BSM 4+1的功能亮点
全程可视化的IT服务管理
通过可视化的管理和监控，降低了复杂系统管理的技术门槛，让系统管理员花更多时间在维护工作上，而不是花很多时间在学习怎么操作比较难的技术平台。
展现效果更加直观，易于理解。枯燥乏味的数据信息，通过直观的图形化展示，使系统管理员对于IT资源的营运状态一目了然。
可视化的展现平台，也给企业CIO和技术工程师之间搭建了沟通的平台，而不是再共同面对那些密密麻麻的数据信息。使技术执行与管理决策之间达成默契。
全程自动化的IT服务管理
自动化的资产发现，让设备的管理更为清晰透明。让遍布在企业各办公区各个角落的所有设备都一目了然。
快速的发现企业的网络设备，并根据发现设备之间的关系自动生成全局的网络拓扑结构图。当发生变化时，自动发现引擎能够及时调整网络的拓扑结构图，保证了与实际网络状态的一致。
对各种指标超标和故障，自动触发报警和故障处理流程。
统一的监控管理界面
上至庞大的电信运营商，下到中小企业都非常愿意拥有操作界面统一，一个WEB站点完成所有管理操作的Portal。而Mocha BSM正给用户提供了大量的“一览式”界面，很方便让用户对企业 IT 服务的全局拥有更深层的认识。
为不同角色，提供所需的IT运维内容
Mocha BSM提供灵活的可定义策略，通过Portlet技术给用户展现企业各资源状态，按照管理所需，随意定义监控视图；
提供Top 10排名榜，让用户一目了然了解最耗CPU，内存资源的服务等信息；
采用B/S架构，从监控—管理—报表分析，全部在唯一的管理Portal完成，省却了大量的系统切换工作，提高了管理人员的工作效率。
全生命周期的IT资产管理
Mocha ITAM可以给IT管理人员一个清楚的全局IT资产状况，比如还有多少库存，多少机器在维修等信息。这样极大的减少了企业在IT资产投资的浪费，Mocha ITAM也是市场上少数提供追踪IT资产生命周期功能的产品。
通过系统，客户现在能通过业务流程来管理各个阶段(采购、入库、维修、借调、借用、折旧、报废)，确保给予IT资产提供全方位的管理以及优化。
最终，管理者更能在各个阶段做出准确的采购决策以及确保IT资产的规范化管理。
端到端响应时间管理
端到端反应时间监控，能够对企业越来越复杂的、跨应用平台的IT系统进行端到端监控，分段了解每一个相关系统的事务情况以及反应时间，一旦出现故障，系统管理员能够快速而准确地判断故障所在，定位服务故障的根本原因，并且快速排除问题。
企业的Portal门户
Mocha RTM能够提前录入登录动态web页面的各种动作，定时自动执行URL页面登录操作，并分析关键值返回结果，验证web的服务状态。
分布式可扩展的技术架构
Mocha BSM采用CMS（Central Monitoring Server 中央监控服务器）、DCH（Data Collection Hub 数据采集集线器）、DMS（Distributed Monitoring Server 分布式监控服务器）三层分布式架构。
DCH支持纵向与横向扩展，即可配置多个DCH在同一个CMS下（横向扩展），每个DCH下还可再配置DCH（纵向扩展）。
DMS支持横向扩展，可配置多个DMS在同一个DCH下。每个DMS下最多可监控1000个资源，消除了被监控资源的数量上的限制。
多种的预警与报警方式
提供了包括桌面预警小帮手（Mocha Alert）、邮件、短信、语音电话等多种报警与预警。
可追踪、可监控、自定义的服务流程
通过拖拽式的可视化流程定义方式，用户可以自定义触发不同的服务流程；
处理过程从触发到最终办理完成，得到了完整的记录；这些记录，可以作为企业的宝贵知识资产，供IT维护人员查询、借鉴。
自定义符合要求的报表与报告
上级领导的定期检查与IT服务成果的阶段性汇报，都需要完整多样的报告与报表的支持；
以拖拽的所见即所得方式，自定义符合需求的报告格式；
可以按照，周报、月报、年报的形式导出，紧急情况下的各种及时报告，可以随时定义，随时导出。大大节约了时间。
与第三方监控系统的整合
支持与主流第三方监控软件厂商的数据和事件整合，保护了企业现有投资，避免了Agent License的浪费。 关于自动化运维平台架构和自动化运维技术栈的介绍到此就结束了，不知道你从中找到你需要的信息了吗 ？如果你还想了解更多这方面的信息，记得收藏关注本站。 自动化运维平台架构的介绍就聊到这里吧，感谢你花时间阅读本站内容，更多关于自动化运维技术栈、自动化运维平台架构的信息别忘了在本站进行查找喔。