后台服务标准化运营 精

为什么要服务标准化

一套互联网后台服务的开发和运营涉及到非常多的细节:

  1. 访问其他服务模块,服务端IP如何管理?网络报文格式是怎样的?

  2. 有哪些配置文件? 用到哪些第三方的库?

  3. 业务逻辑和基础框架是如何分离的?

  4. 对外提供怎样的网络接口?怎么对外提供接口API和文档?

  5. 运营机器上的安装目录准备怎么安排? 有哪些运维脚本和工具?

  6. 应该监控哪些指标?应该记录哪些日志?

  7. 还有很多…

上面种种细节,每个程序员实现起来都有不同的做法。经验证明,如果后台各个模块没有标准化和规范化,可能导致:

  1. 同一个团队开发的服务,千差万别千奇百怪,负责运维的同事面对的多个模块“长”的都不一样,程序框架完全不一样,安装目录乱七八糟,无法规模化的高效运维

  2. 服务的质量完全依赖团队成员的技能和意识,有的成员可能会做得比较好,配置文件命名易懂、文档及时更新与代码保持一致、有对服务做细致的监控上报和日志记录,提供了运维脚本,但是也有的成员的工作让人抓狂

  3. 每当有团队成员离职和工作交接,交接本身就是工作量很大,交接时间长,交接质量不好,文档缺失,很多信息在交接过程中丢失,运营事故往往频发

  4. 经验难以得到传承,一块石头反复绊倒各个成员和业务模块,运营事故雷同、频出,团队挫折感倍增、服务可用性低下

  5. 也曾经有过做事比较规范的时候,但是这些规范通常靠耳提面命、人口相传,靠管理者运动式的整顿,有时候管理焦点没有持续跟进,或者随着人员更替,团队又把这些宝贵的经验丢弃了,变得无序

所以服务标准化是后台技术团队组建开始的第一要务。

几个误区

误区一:找几个开源的组件用起来就好了呗

通常的开源的组件,只是在某一方面上规范了服务,有的是规范了网络调用,有的是规范了如何监控,有的是规范了如何记录远程记录,其实这还远远不够,例如配置文件、接口定义、使用到的外部库、安装目录的结构等非常多的细节,必须统一管理、有唯一出处。

误区二:你说的我都懂,我们团队刚起步,业务需求多,时间紧,先野蛮生长,打破条条框框,后面再规范再改

一开始没有标准化,后面当代码和模块都多起来了,且都处于运营状态,再改再标准化,难度非常大,成本非常大,风险非常大;另外工欲善其事必先利其器,一开始就标准化好,其实可以让业务跑的更快

毫秒服务引擎(msec, 取英文名Mass Service Engine in Cluster的首字母组合)是腾讯一个开源框架,其创作冲动和构建经验,来自QQ后台团队超过10年的运营思考。服务标准化是毫秒服务引擎设计的重要考量点。

毫秒引擎怎么实现服务标准化?

首先,每个服务的配置都web化、集中管理起来,包括:

  1. 部署在哪些IP上?
  2. 有且只有一个配置文件
  3. Protocol buffer的接口定义文件
  4. 引用了哪些外部库?例如openssl
  5. 业务逻辑和基础框架分离,业务逻辑以插件形式提供
    然后,每个业务模块部署的目录结构都是确定的:

如上图所示,

  1. 业务部署的目录都是/msec/一级业务名/二级业务名

  2. 都包含bin etc log 等几个目录

  3. ein里面是启停脚本、业务插件msec.so和外部库(如果有)

  4. etc里面是配置文件config.ini

  5. log里面是本地的日志文件

另外,程序员不能随意打破上面的方式。例如临时的另外搞一个自己配置文件什么的,他如果这样做,那下次发布的时候目录会被覆盖,个性化的东西会被删除掉

结语

由于篇幅和时间的限制,这里不能展开阐述。详细的可以见腾讯云服务市场、 毫秒服务引擎官网 ,或者微信公众号:msec-engine

关键字:产品运营, 标准化

版权声明

本文来自互联网用户投稿,文章观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处。如若内容有涉嫌抄袭侵权/违法违规/事实不符,请点击 举报 进行投诉反馈!

相关文章

立即
投稿

微信公众账号

微信扫一扫加关注

返回
顶部