后台服务标准化运营

版权声明：本文由廖念波原创文章，转载请注明出处: 
文章原文连接：https://www.qcloud.com/community/article/148

来源：腾云阁 https://www.qcloud.com/community

 

为何要服务标准化

一套互联网后台服务的开发和运营涉及到很是多的细节：

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