绿岸方舟系统设计原则
– – 业务低偶合 系统高扩展
–
– –
系统高安全
业务弹性大 人员要求低门槛
–
业务高可控性
早期系统构架
COL 用户操作接口层(Web形式表现|权限控制)
数据业务 Data.config
版本业务 GameVer.config
游戏业务 Game.config
服务器业务 Srv.config
网络自动化运维经验分享
绿岸在发展过程中碰到过的问题：

随着服务器数量增加，管理人员随之增加 – 登陆服务器的人越来越多，安全成本随之增加 – 服务器管理流程难以下达，不同的人操作结果总是存在不同程度差 异 – 操作人员审计工作量太大，每天需要审计的命令太多 – 密码管理工作量大定期更换密码工作难以实施 – 配置管理存在比较多的问题 – 人员成本增大，有经验的运维难招 – …………
方舟的展示截图
开启游戏服务
方舟的展示截图
体检服务器
方舟的展示截图
查询服务器上的日志文件
方舟的展示截图
服务器运行环境初始化
方舟的展示截图
并行多服务器执行业务
方舟的展示截图
服务器插件管理
方舟的展示截图
集中配置管理和下发
未来发展的交流
未来我们设想是把自动化运维应用于全部的应用， 管理的范围将由游戏、数据库、网站等，扩展到 全应用领域（负载均衡，域名服务器，邮件服务 器、集群维护等等），现有的架构将不能满足需 求，为了满足将来的发展，我们引入了两个新
Mbus总线层
Mbus是系统核心层，Mbus的设计目标是单台承载2000个管理结点，最大 4000个管理结点，并支持二级管理结构，Mbus业务功能有：
– 负责注册远端服务器，收集服务器运行信息
–
– – – – –
负责业务分发及根据规则判断业务是否可以执行
负责分发和升级远程endpoint 提供本地和远程API调用 负责业务日志存储和管理 保障网络通迅层的安全和可靠性 输入和输出的合法性校验、检查
– 管理所有服务器的密码
–
– – –
更换服务器密码不影响业务系统的使用
配合审计系统，透明化信任服务器间的访问 所有密码通过接口获取 临时密码设置有失效时间
未来发展的交流
我们在监控预警系统中碰到的的问题：
– 监控的目标是什么？
–
–
什么的方式能从海量的监控数据中发现潜在问 题？是否会有横向对比数据的需求？如何实现？
概念：
– – – 容器 服务 资产管理
接入三个新系统： – 监控预警
未来发展的交流
我们对容器概念的设想：可为单台，也可为多台服务器组成服 务器组，称为容器。容器需要满足的业务功能设想
– – – – – – 满足业务上的灵活性要求 高度抽象出来的物理层 容器由多个组件组成，组件可以由不同型号硬件 容器的某个组件出现损坏，Mbus在硬件池中加载新的组 件，并实现自动迁移业务 组件上放置Endpoint 多个Endpoint的uid编制到同一个容器id之下
现已经实现的业务
– – – – – – – – – – 数据收集 集中式任务管理 日常游戏业务 配置管理及分发 监控报警 预警功能 密码管理 应用初始化 服务器初始化 …………
方舟给绿岸带来的变化
– – – – – – – 安全性提高，登陆服务器操作大幅下降，一般情况下人员不需要登 陆服务器操作业务 可控制变化，每个业务都有日志，员工操作的可控性强制，操作结 果一致性强，出错率低 运维人数下降，工作人员增长由数的增长变为质的增长 业务即时性提高，部分业务直接接口到业务部门使用，比如抽取业 务数据、服务日志等 技术门槛降低，一般运维操作员可是为毫无经验的应届生，培训一 周既可上岗，并完成平台内所有业务工作 人员工作考核标准明确，工作可量化 业务的灵活变动系统都可以支持，且基本上框架无须改变，编制对 应的插件和UI即可支持
–
更换组件的时候只需要容器更换一个Endpoint的uid
未来发展的交流
我们服务概念的设想：一个业务集合可以称之为一 个服务，业务中的个体称为模块，服务具有的业 务特性
– – 服务是高度抽象的应用层 服务可以由多个模块组成
–
– –
多个服务可以存在于一个容器的最小单位上（单 台物理机）
一个服务必须装载在一个容器之内，一个容器可 由一台或多台物理机器组成 模块应有配置要求，并且配置要求可以根据业务 调整
–
–
Endpoint的代码设计和业务无任何关系，实现业 务层完全剥离
Endpoint内嵌Python解释器，可兼容Windows和 Linux平台
Endpointe脚本插件
脚本插件是业务实现的核心，所有的业务都是由插件实现的， 插件的实现目的：
– – – – – 实现业务与系统之间的拆分，发挥插件的灵活性 插件开发尊遁插件开发框架开发，降低插件开发门槛， 一般的运维人员可以快速上手 插件主要以Python程序编制，配合Shell可完成复杂的业 务，并已实现和Endpoint联动完成工作 插件的版本由Mbus管理，Mbus负责插件的升级维护，可 以做到集中式管理所有业务插件 插件的安全性在上线时审计，Mbus和Endpoint按规则发 现可能存在问题的插件组
日志 容器 Builderlog. config
CIL(用户服务程序接口层 Service.config )
RSRL(远程服务运行层)
RSRL(远程服务运行层)
RSRL(远程服务运行层)
以上系统的问题：
– 配置复杂、管理配置文件花费精力较多
–
– –
业务存在冗余，同业务可能需要去更改几个配置 文件
前台权限控制和业务管理不能业务化，部分业务 管理功能仍然需要技术参与 业务弹性还是仍然偏低
现在系统结构
＊
运维维护员 技术客服监控 产品操作员 平台管理员
COL 用户操作接口层(Web形式表现|权限控制|操作日志) 日志 容器 Builderlog. config
Mbus总线
通讯层
WEB-API
插件-API
日志系统
插件库
Endpoint (远程服务运行层)
Endpoint (远程服务运行层)
–
模块对应配置有属性表，依据模块属性可控制每
未来发展的交流
资产管理系和方舟相关内容简述：
– 资产管理系统需登记所有硬件配置信息
–
–
为方舟提供接口，方舟从资产系统中使用硬件
资产系统提供高度抽象化设计，所有设备属性均 可以传值给方舟
–
通过资产系统和方舟做配置管理、优化，提供事 物保障
未来发展的交流
密码系统实现的功能：
Endpoint结点
Endpoint是服务器上的执行端具有高安全性设计、 极简结构、高效数据分段返回的特性，以下是 Endpoint功能介绍：
– Endpoint本身并无监听，而是启动后直接Mbus或 是二级节点，将自身注册至Mbus上
–
–
每个Endpoint都有唯一的Uid
Endpoint提供C++调Python接口和Python调C++接 口
预警系统最大的价值是什么？
–
–
预警系统怎样才能减少误报？怎样和业务系统的 状态实现联动？
海量数据的分析机制如何建立？
–
不同服务之间的监控数据如何实现监ห้องสมุดไป่ตู้平台化？
Endpoint (远程服务运行层)
用户操作接口层
设计目标：高扩展性、模块化、组件化
– 提供WEB前端支持所有业务操作
–
– – – –
提供业务管理功能（不再使用配置文件）
提供权限系统 提供配置管理API（用于和其他业务系统对接） 具有任务分发、授权、定时等功能 登陆后展示公告板，发布运营信息
–
–
提供一个轻量型的知识库，业务人员可管理和发 布自己的知识，便于业务人员检索 …………