后台服务标准化运营 精
为什么要服务标准化
一套互联网后台服务的开发和运营涉及到非常多的细节：
访问其他服务模块，服务端IP如何管理？网络报文格式是怎样的？
有哪些配置文件？ 用到哪些第三方的库？
业务逻辑和基础框架是如何分离的？
对外提供怎样的网络接口？怎么对外提供接口API和文档？
运营机器上的安装目录准备怎么安排？ 有哪些运维脚本和工具？
应该监控哪些指标？应该记录哪些日志？
还有很多…
上面种种细节，每个程序员实现起来都有不同的做法。经验证明，如果后台各个模块没有标准化和规范化，可能导致：
同一个团队开发的服务，千差万别千奇百怪，负责运维的同事面对的多个模块“长”的都不一样，程序框架完全不一样，安装目录乱七八糟，无法规模化的高效运维
服务的质量完全依赖团队成员的技能和意识，有的成员可能会做得比较好，配置文件命名易懂、文档及时更新与代码保持一致、有对服务做细致的监控上报和日志记录，提供了运维脚本，但是也有的成员的工作让人抓狂
每当有团队成员离职和工作交接，交接本身就是工作量很大，交接时间长，交接质量不好，文档缺失，很多信息在交接过程中丢失，运营事故往往频发
经验难以得到传承，一块石头反复绊倒各个成员和业务模块，运营事故雷同、频出，团队挫折感倍增、服务可用性低下
也曾经有过做事比较规范的时候，但是这些规范通常靠耳提面命、人口相传，靠管理者运动式的整顿，有时候管理焦点没有持续跟进，或者随着人员更替，团队又把这些宝贵的经验丢弃了，变得无序
所以服务标准化是后台技术团队组建开始的第一要务。
几个误区
误区一：找几个开源的组件用起来就好了呗
通常的开源的组件，只是在某一方面上规范了服务，有的是规范了网络调用，有的是规范了如何监控，有的是规范了如何记录远程记录，其实这还远远不够，例如配置文件、接口定义、使用到的外部库、安装目录的结构等非常多的细节，必须统一管理、有唯一出处。
误区二：你说的我都懂，我们团队刚起步，业务需求多，时间紧，先野蛮生长，打破条条框框，后面再规范再改
一开始没有标准化，后面当代码和模块都多起来了，且都处于运营状态，再改再标准化，难度非常大，成本非常大，风险非常大；另外工欲善其事必先利其器，一开始就标准化好，其实可以让业务跑的更快
毫秒服务引擎(msec, 取英文名Mass Service Engine in Cluster的首字母组合)是腾讯一个开源框架，其创作冲动和构建经验，来自QQ后台团队超过10年的运营思考。服务标准化是毫秒服务引擎设计的重要考量点。
毫秒引擎怎么实现服务标准化？
首先，每个服务的配置都web化、集中管理起来，包括：
- 部署在哪些IP上？
- 有且只有一个配置文件
- Protocol buffer的接口定义文件
- 引用了哪些外部库？例如openssl
- 业务逻辑和基础框架分离，业务逻辑以插件形式提供
然后，每个业务模块部署的目录结构都是确定的：
如上图所示，
业务部署的目录都是/msec/一级业务名/二级业务名
都包含bin etc log 等几个目录
ein里面是启停脚本、业务插件msec.so和外部库（如果有）
etc里面是配置文件config.ini
log里面是本地的日志文件
另外，程序员不能随意打破上面的方式。例如临时的另外搞一个自己配置文件什么的，他如果这样做，那下次发布的时候目录会被覆盖，个性化的东西会被删除掉
结语
由于篇幅和时间的限制，这里不能展开阐述。详细的可以见腾讯云服务市场、 毫秒服务引擎官网 ，或者微信公众号:msec-engine
关键字：产品运营, 标准化
本文来自互联网用户投稿，文章观点仅代表作者本人，不代表本站立场，不承担相关法律责任。如若转载，请注明出处。 如若内容造成侵权/违法违规/事实不符，请点击【内容举报】进行投诉反馈！