后台服务标准化运营

为什么要服务标准化

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

  1. 访问其他服务模块,服务端IP如何管理?网络报文格式是怎样的?
  2. 有哪些配置文件? 用到哪些第三方的库?
  3. 业务逻辑和基础框架是如何分离的?
  4. 对外提供怎样的网络接口?怎么对外提供接口API和文档?
  5. 运营机器上的安装目录准备怎么安排? 有哪些运维脚本和工具?
  6. 应该监控哪些指标?应该记录哪些日志?
  7. 还有很多…

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

  1. 同一个团队开发的服务,千差万别千奇百怪,负责运维的同事面对的多个模块“长”的都不一样,程序框架完全不一样,安装目录乱七八糟,无法规模化的高效运维
  2. 服务的质量完全依赖团队成员的技能和意识,有的成员可能会做得比较好,配置文件命名易懂、文档及时更新与代码保持一致、有对服务做细致的监控上报和日志记录,提供了运维脚本,但是也有的成员的工作让人抓狂
  3. 每当有团队成员离职和工作交接,交接本身就是工作量很大,交接时间长,交接质量不好,文档缺失,很多信息在交接过程中丢失,运营事故往往频发
  4. 经验难以得到传承,一块石头反复绊倒各个成员和业务模块,运营事故雷同、频出,团队挫折感倍增、服务可用性低下
  5. 也曾经有过做事比较规范的时候,但是这些规范通常靠耳提面命、人口相传,靠管理者运动式的整顿,有时候管理焦点没有持续跟进,或者随着人员更替,团队又把这些宝贵的经验丢弃了,变得无序

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

几个误区

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

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

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

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

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

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

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

部署在哪些IP上?

有且只有一个配置文件

Protocol buffer的接口定义文件

引用了哪些外部库?例如openssl

业务逻辑和基础框架分离,业务逻辑以插件形式提供

然后,每个业务模块部署的目录结构都是确定的:

如上图所示,

  1. 业务部署的目录都是/msec/一级业务名/二级业务名
  2. 都包含bin etc log 等几个目录
  3. ein里面是启停脚本、业务插件msec.so和外部库(如果有)
  4. etc里面是配置文件config.ini
  5. log里面是本地的日志文件

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

结语

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

原创声明,本文系作者授权云+社区发表,未经许可,不得转载。

如有侵权,请联系 yunjia_community@tencent.com 删除。

编辑于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏EAWorld

普元DevOps5.2版本新特性发布

伴随新版本的发布,我们团队也对这次迭代做了些回顾,有值得分享的新特性与设计,也有一些需加强的能力,借此与大家分享。

1184
来自专栏北京马哥教育

业务运维部门的岗位价值与DCOS

岗位价值有: 权限缩小 提供操作安全的保险服务 提供操作的可扩展性 提供业务和资源能见度 屏蔽资源的部署细节 静态资源调平 动态资源调平 故障处理和善后 权...

3424
来自专栏BestSDK

从架构到应用,全面解析混合云的优势

云计算在2016年有了极大的增长。一方面,AWS、阿里云等大型公有云厂商的云计算收入呈爆发式增长且绝对值数据可观;另一方面,通过持续市场培育,云计算的价值逐步被...

3446
来自专栏IT大咖说

如何支撑微服务架构落地

编辑IT大咖说 阅读字数: 2265 用时: 7分钟 ? ? 摘要 如今微服务如日中天,优势和弊端也有各种描述,那么我们是否应该采用微服务架构?如何规避微服务的...

3409
来自专栏程序猿DD

微服务(Microservices)【翻译】

前言 今天跟同事们讨论了很久关于微服务实施过程中涉及的服务拆分、团队边界、技术选型等问题。期间提出的不少问题,也引发了很多新的思考。虽然在Martin Fowl...

1839
来自专栏极限编程

微服务架构下的测试应对策略(上)

伴随着互联网的快速发展,Web应用系统从面向企业内部发展到面向市场用户,业务的日趋复杂以及用户量的上升,那些曾经工作良好的单体应用开始遇到开发、测试、部署、发布...

984
来自专栏非著名程序员

如何优雅的抄袭代码?天下代码一大抄,这才是正确的姿势

你们知道程序员最熟悉,最熟练,最常用的两个快捷键是哪两个吗?没错,估计你现在心中所想的就是:ctrl+c 和 ctrl+v ,俗名为:复制和粘贴。对于大部分程序...

2878
来自专栏后端技术探索

58同城沈剑:好的架构源于不停地衍变,而非设计

对很多创业公司而言,很难在初期就预估到流量十倍、百倍以及千倍以后网站架构会是什么样的一个状况。同时,如果系统初期就设计一个千万级并发的流量架构,很难有公司可以支...

661
来自专栏企鹅号快讯

简析Linux主要应用领域及范围

Linux操作系统主要有以下三大应用领域: 1. Linux作为企业级服务器的应用 Linux系统可以为企业架构WWW服务器、数据库服务器、负载均衡服务器、邮件...

1858
来自专栏云计算D1net

使用PaaS实现更好的云应用安全性

如今,最流行的云计算模式就是基础设施即服务(IaaS),但是它并不总是云应用安全的最佳模式。很多用户都知道平台即服务(PaaS)和软件即服务(SaaS)可以实现...

3037

扫码关注云+社区