福州网站seo,asp.net做网站的流程,缪斯设计公司官网,python基础教程题库腾讯QQ团队将于12月4日开源一个服务开发运营框架#xff0c;叫做毫秒服务引擎#xff08;Mass Service Engine in Cluster#xff0c;MSEC#xff09;#xff0c;它集RPC、名字发现服务、负载均衡、业务监控、灰度发布、容量管理、日志管理、Key-Value存储于一体#xff… 腾讯QQ团队将于12月4日开源一个服务开发运营框架叫做毫秒服务引擎Mass Service Engine in ClusterMSEC它集RPC、名字发现服务、负载均衡、业务监控、灰度发布、容量管理、日志管理、Key-Value存储于一体目的是提高开发与运营的效率和质量。 毫秒服务引擎的创作冲动和构建经验来自QQ后台团队超过10年的运营思考。它是一整套解决方案但也可以拆分来使用其中的监控、Key-Value存储单品。 典型用户群体 毫秒服务引擎非常容易搭建和上手使用它初学者从零开始开发一个分布式后台demo并运行起来只需要2个小时。基本上是一个小时完成框架搭建一个小时完成开发上线特别适合互联网初创公司。 功能与优势 模块间访问采用RPC的方式开发者不用关注网络与报文格式像写单机程序一样开发分布式服务。 负载自动均衡与容错对于单机故障、局部网络波动等状况自动应对服务高可用性。支持C/C、Java、PHP语言马上还会推出支持Python语言如果选择C/C语言支持协程兼具开发和运行效率。Web化的管理界面在Web界面完成配置、发布、监控、日志、Key-Value存储集群管理等所有操作。需要复杂部署的服务器都采用Docker镜像的方式安装使得部署与上手非常容易。相比使用其他开源组件拼凑起来的解决方案毫秒服务引擎更加的体系化对团队的规范更加到位。 毫秒服务引擎设计背景 对于互联网服务后台团队开发框架的选择是非常关键的问题10年的海量服务经验和教训使得我们团队深刻认识到 要尽早规范团队的开发服务框架避免到了后期各种开发语言混杂、各类存储组件充斥、重复编码、每个模块形态不统一、文档缺失、监控瘫痪、人员离职造成大量信息丢失最后积重难返、痛苦不堪没有框架来规范团队的随意性就太大合作效率就大打折扣甚至于内耗、反复的挖坑填坑系统的成败过于依靠人的意识和水平规范不能靠文档、不能靠劳动纪律、不能靠苦口婆心、不能靠人员意识、不能靠运动式的整顿要靠技术框架上切实的限制与贴心保护。 如果有机会从零开始定义一个理想的开发框架我们觉得需要考虑下面9点。 同步编码异步执行。兼顾运行效率和编码效率希望代码写起来是同步和顺序的而执行的时候是异步的。IDL/RPC。支持IDL接口描述语言和RPC减少网络协议相关的重复工作协议有比较好的扩展性远程调用友好且高效做到覆盖主要的开发语言。LB。对服务间的调用选路进行统一的管理对单机故障和网络波动等常见情况有自动容错我们简称load balanceLB。存储服务化。这个其实和开发框架关系不太紧密这里提一下强调存储应该有统一的组件且由专业的团队运维就像共有云一样。过载保护。框架必须有成熟自带的过载保护机制不需要业务开发人员关注或者关注很少。基础的监控和告警。RPC调用、机器的CPU/网络活动、任务并发度、时延、进程监控和秒起等基础信息要有上报、统计和告警不需要业务开发人员关注。完整的业务流转呈现。统一日志在一个地方能够清晰的呈现某次业务处理过程的流转详细情况经过了哪些模块间调用调用参数是怎样的每个模块处理的重要分支和结果是怎样的最好图形化呈现。支持染色和不同的日志详细级别。中央总控。整个系统的配置和文档等重要信息例如每个模块有哪些机器分布在哪些机房、容量冗余情况、模块间调用关系、访问控制的配置动态管理甚至电子流都希望能统一在一个地方Web化的管理起来并且与运营的系统是直接联系直接生效的。云调度。容量的自动调度。例如要进行某个运营活动需要大量的扩容只需要把设备放进去就能自动的扩缩容。当某个城市机房故障能够自动调度容量到其他城市。 毫秒服务引擎架构 整个系统由下面几部分组成如图所示。 **Web Console**整个系统的运营管理中心包括 Tomcat提供Web管理界面管理的数据保存在MySQL里。 LB是名字发现服务和负载均衡remote_shell是远程文件传输与远程命令执行服务。 **Log服务器**提供业务Log的存储和查询服务。Log存储在MySQL表里。 **Monitor服务器**提供业务上报信息的存储和查询服务。业务上报信息存储在内存里推荐内存8G~16G。定时dump到磁盘的方式防止数据掉电丢失。 **业务运营服务器**部署开发框架和业务逻辑代码处理业务请求。 **key-value存储服务**相对整个框架比较独立按需选用。 服务标准化运营 一套互联网后台服务的开发和运营涉及非常多的细节。 访问其他服务模块服务端IP如何管理网络报文格式是怎样的 有哪些配置文件 用到哪些第三方的库 业务逻辑和基础框架是如何分离的 对外提供怎样的网络接口怎么对外提供接口API和文档 运营机器上的安装目录准备怎么安排 有哪些运维脚本和工具 应该监控哪些指标应该记录哪些日志 还有很多… 上面种种细节每个程序员实现起来都有不同的做法。经验证明如果后台各个模块没有标准化和规范化可能导致同一个团队开发的服务千差万别千奇百怪负责运维的同事面对的多个模块“长”的都不一样程序框架完全不一样安装目录乱七八糟无法规模化的高效运维。 服务的质量完全依赖团队成员的技能和意识有的成员可能会做得比较好配置文件命名易懂、文档及时更新与代码保持一致、有对服务做细致的监控上报和日志记录提供了运维脚本但是也有的成员的工作让人抓狂。 每当有团队成员离职和工作交接交接本身就是工作量很大交接时间长交接质量不好文档缺失很多信息在交接过程中丢失运营事故往往频发。 经验难以得到传承一块石头反复绊倒各个成员和业务模块运营事故雷同、频出团队挫折感倍增、服务可用性低下。 也曾经有过做事比较规范的时候但是这些规范通常靠耳提面命、人口相传靠管理者运动式的整顿有时候管理焦点没有持续跟进或者随着人员更替团队又把这些宝贵的经验丢弃了变得无序。 所以服务标准化是后台技术团队组建开始的第一要务。 两个误区 **误区一**找几个开源的组件用起来就好了呗。 通常的开源的组件只是在某一方面上规范了服务有的是规范了网络调用有的是规范了如何监控有的是规范了如何记录远程记录其实这还远远不够例如配置文件、接口定义、使用到的外部库、安装目录的结构等非常多的细节必须统一管理、有唯一出处。**误区二**你说的我都懂我们团队刚起步业务需求多时间紧先野蛮生长打破条条框框后面再规范再改。 一开始没有标准化后面当代码和模块都多起来了且都处于运营状态再改再标准化难度非常大成本非常大风险非常大另外工欲善其事必先利其器一开始就标准化好其实可以让业务跑的更快。如何实现服务标准化 首先每个服务的配置都Web化、集中管理起来。 部署在哪些IP上 有且只有一个配置文件。 Protocol buffer的接口定义文件。 引用了哪些外部库例如openssl。 业务逻辑和基础框架分离业务逻辑以插件形式提供。 然后每个业务模块部署的目录结构都是确定的。 如上图所示 业务部署的目录都是/msec/一级业务名/二级业务名 都包含bin etc log 等几个目录 bin里面是启停脚本、业务插件msec.so和外部库如果有 etc里面是配置文件config.ini Log里面是本地的日志文件。 另外程序员不能随意打破上面的方式。例如临时的另外搞一个自己配置文件什么的他如果这样做那下次发布的时候目录会被覆盖个性化的东西会被删除掉。 后台服务的RPC和路由管理 互联网服务的后台硬件通常是由大量的廉价机器组成软件架构通常采取大系统小做、分而治之的思想。这就决定了业务逻辑涉及到大量的网路IO同时单机故障、网络局部故障是运营的常态。那么RPC和路由管理就显得尤其重要了。毫秒服务引擎为此提供了一个完整的解决方案。 RPC的概念其实出现已经很久了记得笔者读大学的时候接触到RPC的概念总觉得不重要多此一举。 我掌握好Socket通信这个利器和TCP/IP协议族原理什么功能不能实现 RPC就跟本地函数调用一样写代码确实开发效率比较高我自己把Socket相关函数好好封装一下让代码复用起来开发效率也很高。 不懂或者不关注网络通信底层原理光会函数调来调去这样的程序员太没有出息了 后来笔者开始带团队亲身经历了一些团队协作和IT服务运营过程中的故事才发现RPC非常关键。如果没有很好的实现RPC和路由管理IT系统服务质量会过度的依赖人的意识而这个通常成本非常高、效果也不好。 毫秒服务引擎是怎么做的 首先毫秒服务引擎将每个服务部署在哪些IP上这些信息集中管理起来即使是调用外部的非标准服务我们叫异构服务也需要将该外部服务的接口IP配置到毫秒服务引擎管理系统里。这样涉及到的IP信息就不会散落在代码和各种配置文件里了。 服务之间的调用统一采用CallMethod()函数的方式避免代码千奇百怪按服务名字调用和接口名调用。 RPC背后的路由算法对于单机故障、网络局部波动等异常自动容错。简单的说路由算法按一定的规则轮转的选择被调用模块的接口机并统计过去一段时间的调用成功率、时延信息根据这些信息调整该接口机被选择到的比例。如果某个接口机故障了那么就不会发送请求给它从而实现自动容错。 毫秒服务引擎框架本身在RPC执行的时候就上报了很多基础属性和日志这样保证了服务监控和告警等运营措施不依赖与人的意识。下图是叫做getMP3List这样一个RPC调用的请求数和成功数这些是不需要业务开发者工作就自动上报。 每个请求有唯一ID来标识通过该ID毫秒服务引擎可以在框图中直观的呈现该请求经过的模块、模块间的RPC名字等信息这个同样不需要业务开发者的工作就自动实现。 后台服务的灰度发布与监控 灰度发布和监控是互联网海量服务必备的两大利器能够极大提高后台服务可用性和运营水平背后的哲学是持续交付、用户测试和尽在掌控。 在腾讯有一个课程系列叫做《海量服务之道》包含十多门课程和方法论是技术同事必修和必知必会的其中两门课程就是《灰度发布》和《全方位监控》。 笔者在加入腾讯QQ后台团队之前曾经在电信行业、金融行业做过几年开发工作。刚进入腾讯时觉得技术上很多地方让人耳目一新。 后台系统都是部署在非常多的廉价服务器上每个人都会管理非常多的机器让人觉得很有成就感很富有。 有比较精确的设备预算计算模型每个服务器的性能在考虑容灾冗余的前提下通常被压榨到刚刚好负责人会深入的洞悉整个系统的性能、容灾、柔性等方方面面。能负责一个海量的系统是很荣耀的一件事情。 没有专职的测试人员经过开发者自测后灰度发布加详细的监控主要的系统几乎每两周都会被发布一轮作为后台技术人员自己的工作直接影响数以亿计的用户有点手握核弹处于上帝视角的感觉。 监控系统我们内部一个叫monitor的系统真的是太方便了一条条曲线直观的展示整个系统运作的各种指标如果有异常短信和电话就会响起来让人觉得一切尽在掌控有一种面对着大量仪表盘操控着航母游弋或者是战斗机挂着核弹翱翔的感觉。 好了赶紧结束程序员意淫的美好感觉我想说的重点是灰度发布和监控真的是互联网海量服务必备的两大利器能够极大的提高后台服务可用性和运营水平。 当然灰度发布不只是一部分一部分的发布新代码监控也不只是绘制曲线和告警短信那么简单这里面深究下去会有很多东西背后的哲学是持续交付、用户测试和尽在掌控。 毫秒服务引擎是怎么做的 #####灰度发布 在服务配置管理页点击“制定发布计划”。 选择这一次灰度要发布的目标机器和发布类型。 在接下来的向导中选择正确版本的配置文件、外部库、业务插件等这样就完成了发布计划的制作。 接着点击菜单 “运维-发布”可以查询所有发布计划对于已经发布的计划可以做回滚操作。点击详情可以查看发布计划更详细信息并执行发布。 监控 关于监控在“RPC和路由管理”那里讲得已经比较详细了这里不赘述。只说明一下除了RPC和框架本身自动上报的一些信息还支持业务自定义上报信息例如我想上报第28级VIP用户登录的次数且支持对于关键指标的波动、最大值、最小值设置告警。 KV存储集群的设计要点 Key-Value存储系统是非常普遍的需求几乎每个在线的互联网后台服务都需要KV存储我们团队在KV存储方面经历过几个时期我自己深感要做好不容易。 第一个时期很早期的时候我们的数据存储在MySQL表里按照用户账号简单的分库分表为了保证访问高并发利用每个MySQL服务器的内存做数据缓存主备两套分布在不同IDC业务逻辑自己做副本同步。当时主要的问题是内存的数据结构扩展困难、运维工作琐碎、数据同步机制本身的缺陷导致不能做异地IDC部署这些缺点对于业务飞速发展、一地机房已经不够用的局面非常被动。 第二个时期我们设计了新的KV存储系统其用户数据结构容易扩展、具备可以多地部署的数据同步机制很好的应对了新时期业务发展的需要。为了设备成本考虑我们把数据做冷热分离访问频繁的数据会加载到专门的Cache层且对于不同的访问模型挂载不同架构的Cache另外一个File层专门做数据持久化。这样的设计使得架构太复杂bug收敛速度慢运维工作相比以前甚至更复杂了。 第三个时期为了应对普遍的KV存储需求我们以公共组件的形式重新设计了KV存储作为团队标准的组件之一得到了大规模的应用。结合同期抽象出来的逻辑层框架、路由管理等其他组件团队的公共基础组件和运维设施建设的比较完备了整个业务的开发和运维实现了标准化。但这个阶段就用了我们团队足足2年多时间。 不同于无数据的逻辑层框架KV存储系统的架构设计会更复杂、运维工作更繁琐、运营过程中可能出现的状况更多、bug收敛时间会更长。一句话团队自己做一个KV存储系统是成本很高的而且也有比较高的技术门槛。 设计一个KV存储需要考虑至少这些方面。 如何组织机器的存储介质通常是内存、磁盘文件例如用hash的方式组织内存。 如何设计用户的数据结构使得通用、易于扩展、存储利用率高例如PB序列化、Json、XML方式。 友好的访问接口而不只是get/set一整个value。 如何做集群分布、如何sharding、如何做到方便的扩缩容例如一致性hash算法。 如何做数据冗余、副本间如何同步、一致性问题副本间如何选举master。 备份与恢复、数据校验与容错。 读写性能。 其他可能的特殊需求例如我们设计过一个KV存储用于存储一些公众号的个数不受限粉丝列表。 上面8点业内的KV存储组件一般都会考虑到或者各有特色各自优势在伯仲之间。但是综合过去的经验教训我们觉得有一点很容易被忽视可运维性、运维自动化、黑盒化运维。 举一个例子前面提到的我们第二个时期的KV存储系统刚开始应用的时候一次扩容过程会有10多步的运维操作包括load数据、做增量同步、多次修改机器状态、数据比对等等需要运维同事以高度的责任心来完成。另外就是运维同事必须如该KV存储架构设计者一样深刻理解系统背后的原理和细节否则就不能很好的执行运维操作这个要求也非常高新老交接周期长还容易出运维事故。 基于上面的考虑同事为了让用户更容易学习和接受毫秒服务引擎在Redis Cluster的基础上实现了运维Web化并加上了集群的监控。 通过Web界面方便进行 集群概要状态查看。 可以在Web上方便的完成日常的运维操作新搭集群、扩缩容、故障机器的恢复。 请求量、内存使用、CPU等各种状态信息可直观监控也可以按IP粒度查看。
