msec

分布式后台服务引擎
授权协议 GGPL
开发语言 Java C/C++
所属分类 程序开发、 服务框架/平台
软件类型 开源软件
地区 国产
投 递 者 越学博
操作系统 跨平台
开源组织 腾讯
适用人群 未知
 软件概览

毫秒服务引擎(msec, 取英文名Mass Service Engine in Cluster的首字母组合)是腾讯的一个开源框架,适用于在廉价机器组成的集群上开发和运营分布式后台服务。毫秒服务引擎集RPC、名字发现服务、负载均衡、业务监控、灰度发布、容量管理、日志管理、key-value存储于一体,目的是提高开发与运营的效率和质量。 

毫秒服务引擎的创作冲动和构建经验,来自QQ后台团队超过10年的运营思考。它是一整套解决方案,但也可以拆分的来使用其中的监控、key-value存储单品。 

应用场景

web console:整个系统的运营管理中心。 主要是:
① LB是名字发现服务和负载均衡。
② remote_shell是远程文件传输与远程命令执行服务。
③ tomcat提供web管理界面,管理的数据保存在mysql里。

业务运营服务器:部署开发框架和业务逻辑代码,处理业务请求。

log服务器:提供业务log的存储和查询服务。Log存储在mysql表里。

monitor服务器:提供业务上报信息的存储和查询服务。业务上报信息存储在内存里,推荐内存8G~16G。定时dump到磁盘的方式防止数据掉电丢失。

key-value存储服务:相对整个框架比较独立,按需选用。

典型用户群体

使用毫秒服务引擎,用户可以快速拥有一套具备监控、名字发现服务、负载均衡、灰度发布、配置管理、日志、kv存储等功能的系统化的开发与运营框架,特别适合互联网初创公司。

10年的海量服务开发运营经验和教训使得我们深刻的认识到:

  • 要尽早规范团队的开发服务框架,避免到了后期,各种开发语言混杂、各类存储组件充斥、重复编码、每个模块形态不统一、文档缺失、监控瘫痪、人员离职造成大量信息丢失,最后积重难返、痛苦不堪。

  • 没有框架来规范,团队的随意性就太大,合作效率就大打折扣,甚至于内耗、反复的挖坑填坑,系统的成败过于依靠人的意识和水平。

  • 规范,不能靠文档、不能靠劳动纪律、不能靠苦口婆心、不能靠人员意识、不能靠运动式的整顿,要靠技术框架上切实的限制与贴心保护。

特点与优势

  1. 模块间访问采用RPC的方式,开发者不用关注网络与报文格式,像写单机程序一样开发分布式服务。

  2. 负载自动均衡与容错,对于单机故障、局部网络波动等状况自动应对,服务高可用性。

  3. 支持C/C++与Java语言,后续还将继续丰富;如果选择C/C++语言,支持协程,兼具开发和运行效率。

  4. Web化的管理界面,在web界面完成配置、发布、监控、日志、Key-value存储集群管理等所有操作。

  5. 需要复杂部署的服务器都采用Docker镜像的方式安装,使得部署与上手非常容易。

  6. 相比使用其他开源组件拼凑起来的解决方案,毫秒服务引擎更加的体系化,对团队的规范更加到位。

介绍内容来自 聊聊架构

  • 使用ping命令时,经常出来msec和usec。 msec是毫秒; usec是微秒   ms意思是“毫秒”,1秒=1000毫秒 us应为μs,是指“微秒”,1毫秒=1000微秒,即1秒=1000,000微秒。 ns是“纳秒”,1微秒=1000纳秒, 即1秒=1000,000,000纳秒

  • https://github.com/Tencent/MSEC

  • 简介 MSEC是一个开发+运营解决方案,不只是一个开发框架,适用于在廉价机器组成的集群上开发和运营分布式的互联网后台服务。MSEC的创作冲动和构建经验,来自QQ后台团队近10年的运营思考。 MSEC是简单的,它没有复杂的配置,也没有用到高深的技术。架构非常简单,有一定计算机基础的人都能很快理解它并掌握它。 特性 RPC和自动路由:基于MSEC开发分布式后台服务,不需要关注网络调用、不需要关注负载均

  • spp 主要进程分为3类: controller进程:主要负责controller,通过消息队列来监控proxy和worker的健康 proxy进程:负责接受用户请求,讲请求数据写入到共享内存 work进程:业务处理逻辑,从共享内存中读取请求数据,进行业务处理完成后,写回到共享内存。 源码路径:https://github.com/Tencent/MSEC

  • 关于QThread::wait(msec)函数的讨论 之前再回帖时候提到线程中的wait函数,文档中是这样描述的 bool QThread::wait ( unsigned long time = ULONG_MAX ) Blocks the thread until either of these conditions is met: -The thread associated with th

  • Derrick Harris writing about 28msec, still-in-stealth-mode, generic query language: Their solution was to create a platform able to extract data from any of these sources, transform it into a standard

  • 我擦来,docker火了那么久,今年又是dcos,又是marathon k8s的,都快玩儿不过来了,企业也来凑热闹,正好下周内存条到位,可以好好把万一翻了。 不过QQ还真小气,下载还得qq验证,干脆传到pan里了: https://pan.baidu.com/s/1qYPcKRM

  • COSBench   time drift between controller and driver-driver1 is 18898997 mSec question: 2016-06-22 11:47:56,749 [INFO] [WorkloadProcessor] - START WORK: init_create_bucket 2016-06-23 00:32:54,000 [INFO

 相关资料
  • 问题内容: 您将使用哪种分布式锁定服务? 要求是: 可以从不同的进程/机器看到的互斥(锁定) 锁定…释放语义 超时后自动释放锁-如果锁持有人死亡,它将在X秒后自动释放 Java实现 很高兴拥有:.Net实现 如果免费:死锁检测/缓解 易于部署,请参阅下面的注释。 我对诸如“可以通过数据库完成”或“可以通过JavaSpaces完成”之类的答案不感兴趣-我知道。我对现成的,现成的,经过验证的实现感兴趣

  • 链接 Web API Controllers 动态WebApi层 集成OData 集成Swagger UI ASPNET Core 集成OData

  • 我想创建一个小应用程序,在后台记录数据。所以我试着用绑定服务。这很好,但如果我关闭应用程序,服务也会停止。< br >那么,我的问题是:使用即时服务来执行这一操作是不是一个好方法?当应用程序关闭时,我如何保持服务在后台运行(我也想在启动后启动它)?

  • 我有两个微服务和调用来更新数据,然后插入另一个数据,但让我们考虑一下 失败,然后我们需要回滚由 更新的数据,否则我们将处于不一致的状态。 我也经历了佐贺patterns.will它满足了这种矛盾 谁能为此提出更好的解决方案?

  • 最近在学微服务的分布式事务,不太明白为什么在微服务这种分布式系统中,原有的单体acid会出现问题 希望大佬们可以讲一下原理和思想

  • 链接 后台作业和后台工人 集成Hangfire 集成Quartz