ITPub博客

首页 > 应用开发 > Java > 快上车!“正经”文章告诉你如何“构建与使用快速响应的分布式中间件平台实践”

快上车!“正经”文章告诉你如何“构建与使用快速响应的分布式中间件平台实践”

原创 Java 作者:格伯纳 时间:2018-08-20 09:36:17 1 删除 编辑

文:徐海峰 徐海峰

首先,请相信我:这是一篇技术文章,正不正经,那就只有看完才能知道了!


前几天,一则“前沿数控因使用腾讯云而数据全部丢失”的新闻震惊了整个IT圈。当我看到这新闻的时候,突然的想法是这样的:

 


不过在我们这个业务为王的特殊环境下确实也不是大新闻。过几天,换个话题就都过去了。但是作为一个技术人,必须要振臂高呼一句:基础建设要自主。

 

所以这次借了   SACC2018   的东风,推出了关于基础建设的深度培训课程: 《构建与使用快速响应的分布式中间件平台实践》 。整个课程从头至尾讲述了怎么样快速并且低成本的构建一个属于自己的中间件平台,从方案的整体架构设计开始,到开发的难点分析,再到真实环境的具体实施过程,以及使用一段时候后对于初版的改进升级等,一应俱全,应有尽有。


整个计划主要分为三个部分:


▍1. 以业务开发为核心驱动的技术栈中间件设计与实现。


这部分主要以Java语言开发为主,主要讲述以Java语言为主开发的技术栈Albianj与任务调度系统Scher与Jinwei系统。


Albianj是一个类似于spring+hbm的高性能扩展版。类比spring与hbm,IOC、DI响应的做了简单化处理,但是增强了对于数据库分库分表的数据路由功能、分布式事务的控制功能等一序列面对海量数据与互联网快速开发要求的实现。


整个albianj不仅仅只有spring与hbm的功能,它更是我们业务开发的核心,整个架构图如下图:

 


Scher与Jinwei是我们任务调度的两个不同类型的区分。他们分别完成定时和实时任务的调度。


 

它们基于Albianj实现,有着相同的物理与逻辑架构,并且有着90%重叠的功能,但是我们却在设计、开发与部署的时候进行了强制性的隔离,这里的原因痛苦而无奈,想知道为什么吗?来,我告诉你。


▍ 2. 高性能开发为主的中间件设计与实现。


这部分主要由linux下的C开发为主,主要讲述我们自我实现的分布式id生成器Chaos,分布式文件系统DFS、分布式缓存系统lest与分布式协调器lax,通讯协议hms与使用JNI实现的http服务Aru。


分布式id生成器Chaos主要为我们的业务生成全站唯一的、可视化、区间内单调递增的id,用于取代老旧的MySQL自增id或者是uuid作为主键的方案。


 

Chaos生成的id和albianj的数据路由进行紧密的配合,可以使开发者在无感知、无侵入的情况下快速而有效的开发出可以抵挡亿级PV的分布式业务系统。


DFS就不用多说了,这是一个互联网公司走向中间件自主的必经之路,也是标志之一。因为我们业务的特殊性,要求对于DFS存储的内容可进行频繁的更改,所以市面上其实并无相应的成熟DFS可用,故我们别无选择。我们在DFS上花了很大的时间进行设计和优化,使其满足我们每天亿级新增/更改的需求。


有了DFS的内容存储,我们又对其增加了一个出口:这就是我们的Arch系统。说起Arch系统,这仅仅是出于我们自己的看不惯和“2”的精神。因为觉得netty太过复杂,所以就动了自己写一个精简NIO的恻隐之心,所以就在“好玩”的驱使下,我们使用JNI自己封装了一个C版本的NIO,然后因为想试试它的完备性、健壮性和性能,思来想去http最简单,那就搞一个小心的http服务器吧。所以arch由此诞生。目前arch运行在我们的图片、音频等项目中,为漫画、精排、封面提供每天亿级访问的服务。

 

对于图片、音频等当然是主要输出就可以了。但是对于内容就没有那么简单了,所以我们在DFS上又增加了一套基于大数据和AI的关键字鉴别与分析系统,这样将DFS完整的平台化。

 

分布式缓存系统lest和分布式协调器lax则不同,他们的出现来自于我们对于缓存管理的无奈和懊恼,还有对于zookeeper的失望。以前我们的缓存使用了26台的redis来进行管理,机器数量增加的同时也增加了成本,并且redis客户端的分布式模式时间长了真的很难管理。所以我们开发了lest,一个不需要大内存而基于ssd的缓存系统。


为了给lest增加严格的版本控制,实验了zookeeper,不管是部署还是性能,都不满足我们的需求和胃口,再者zk的功能太多了,我们又及其讨厌开源软件的“复杂税”,所以在迫于无奈的情况下,我们只能自己开发了分布式协调器lax。从而将lest和lax组合成一个完整的系统。

 

又因为lest和lax的存储与通讯的需要,在研究了google的pb等所谓的通讯协议后,还是不太满意这些开源的通讯协议不要中间协议文件与编译的步骤,所以在此基础上我们构建了hms通讯与存续协议。 



并且是hms不仅仅满足存储与通讯协议的需求,我们更是将hms的对象作为一个对象树,还集成了简单的查询方法,可以提供简单的大于,小于,等于等等查询。

 

▍ 3. 最后一部分


我们将讨论一点哲学问题:人、团队、架构、业务代码之间的4角关系。      

 


说了那么多,其实我就是想表达一个观点:完全自主化中间件并不难。我们一个团队花了没多少时间就开发了那么多的东西,虽然中间也碰到了各种的问题,好在最后都顺利的解决了。


还是印证了那句话:

 


每天的业务开发是不是让你已经厌倦了整天加班的痛苦?

 

所以,你准备好了吗?中间件开发这门艺术几乎就要失传了,你还不赶快来参加我们?


什么?你说完整技术大纲?往下看就是了


识别二维码 查看完整课程大纲


最后,请相信我,这是一篇技术文章!

细心的朋友们已经又在问了,参会的渠道在哪里呢?往这儿看    点击http://sacc.it168.com/goupiao.html就可以直达优惠购票通道了,对了, SACC 2 018 大会门票 8.8 折优惠限时优惠中! 还犹豫什么呢?识别下方二维码就是了。


长按识别上方二维码 立即报名



来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/31509949/viewspace-2212317/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
管理员

注册时间:2018-03-30

  • 博文量
    226
  • 访问量
    571507