后台服务标准化运营

为什么要服务标准化

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

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