云栖大会2016参后感

前日向领导申请,去香格里拉酒店听了云栖大会关于企业互联网架构的分享,这里做一个回顾。

会场感受

云栖大会2016

签到时流程还是比较清晰的,工作人员扫了我的参会二维码生成参会证,然后读取身份证核对身份信息,接着进场。

会场外各公司展台

会场外公司展台,各参会合作公司展示自己的产品,推广交流。中间我在持续交付平台的展台和魔泊云的展台逗留了一下,其他展台并没有看到特别抢眼的。

企业互联网架构专场

随后就是进场了,这里听的比较仔细的是企业互联网专场。

企业互联网专场基本内容

这一块主要是推广内部产品,技术核心就是分布式——在海量级别的用户群前,传统的架构是无法通过扩容升级来支撑这样的流量的,只有通过拆分,分布式服务来横向解决这个问题,这也是天猫双十一给他们带来的宝贵经验(这点在会上被反复提出)。

而实现分布式,企业一般通过自己搭建部署,可能在过程中遇到各种前人走过的坑(当然是不会遇到双十一这种挑战级巨坑),而他们在之前的经验中,将这部分经验整合打包起来,作为一个中间层产品(会上称为中间件)发布。中间层产品是在介于硬件层面与业务系统层之间的一层服务——类似于docker这样的服务我想应该也是算做这一层——通过协调硬件资源与业务系统请求,合理化平衡这些资源与请求。

说的太深奥了,我想简单的说就是,我们的原有的传统系统是业务系统与单机硬件资源的组合,而随着互联网海量需求的增加,传统业务系统与单机硬件资源已经不够用了,这时候就需要扩容,而上面说的中间层就是两方协调,使业务需求海量增加的情况下,硬件资源也能有条不紊的增加,并且能保持原有的传统单机系统与单机硬件资源的运作习惯,减少切换成本。

每个产品的结合自身的想法

上面说的中间层产品大概就是分布式服务框架EDAS,分布式数据库DRDS,异步消息服务MQ,开放搜索OpenSearch这几部分。

关于分布式服务框架

这里我的理解大概就是,这是一个将服务切换为分布式的框架系统,开通也提到了他们在之前所面临过的问题,包括多人维护一个核心工程数据库能力达到上线,数据孤岛。听到这几点问题是,我自然而然的就想到公司里目前遇到同样的问题。

多人维护一套系统目前还不是最大的问题,而数据库能力达到上线,数据孤岛都是我们面临的问题。前几天在部门会议上我也比较简单的说了我对目前公司内部各系统间信息无法互通的想法,看到这里,我想大概大多数企业在某个时期都会遇到同样的问题。解决的方法第一个能想到的就是分布式。

这里的服务分布式,是指将现有的业务系统中,每个功能模块独立出来服务化,例如用户中心,交易中心等,这样多个功能独立出来作为一个服务,提供对应的交互接口。在新上其他业务系统时,这些部分就可以直接通过组合调用来实现相应的模块功能,而不用重新写一套用户系统或重新进行用户信息整合。

每个项目独立出部分服务

他们也是在每个项目中慢慢拆分出不同的服务,当然这样的拆分无疑是不会那么轻松的,会上也提了,那个千岛湖项目本来的意思是,完成了这个项目就去千岛湖游玩一趟。

关于分布式数据库

其实这个在公司的mysql库上已经采用了这样的云数据库,只是目前mysql库的业务量没有达到这个量级,目前也没看出与传统本机数据库有什么大的区别。

之前在公司某个下班后的闲聊中,大家对于SQL Server数据库中某个庞大的表如何拆分进行了一定的讨论。我们能想到的拆分就是在业务层面纵向或者横向拆分。其实更加高效的是在底层进行拆分,在不用动业务层的前提下,对数据库底层进行一定的分布式拆分。我理解到的大概就是,DRDS大概就是在做这样的事情。

数据拆分

因为没有具体用过这个服务,所以这里我不是想说这个服务有多么优秀,而是这样的一种思路,是需要去学习和考虑的。拆分的思路在会上只是大概的提了,比如跨库join,小表广播,异构复制,读写分离,这些提出的思路,在今后实际去做数据拆分,构建分布式数据库时是可以借鉴和需要考虑的。即时不需要做这些工作,对于所用技术原理一定程度的掌握也是需要的。

关于异步消息服务

这是个我基本没有太多接触的领域,在之前的业务系统开发过程中,所有的消息传递基本都是同步的,异步消息只有简单的前端层面偶尔使用,而在面对海量的访问需求时,自然不可能所有的消息传递都是实时同步的,这时就需要把非关键任务的消息作为异步消息。

例如用户注册,那么查询用户名是否存在,写入用户信息等关键信息必须实时同步,而注册后获得100积分奖励,新会员根据区域推荐附近门店等非本次核心需求,就可以在注册完成后异步完成,因为奖励积分,推荐门店等功能并不影响用户的实际注册。

我是这么理解,这个异步消息服务作为服务发布,是为了解决海量的请求数下的分布式处理而构建的。

总结回顾

其实也没啥好总结的,写的也有点乱,只是觉得最后还是要稍微总结一下。总体来说企业互联网架构,我觉得分布式是一个趋势,而服务的拆分共享就如同代码中的复用性一样,也是需要不断优化的。随着时间发展与沉淀,也随着技术的发展,系统改造我估计也一样是不可避免的,在这之前能多了解一些新的思想,以后应用的过程中就多了一些经验。

服务化改造

坚持原创技术分享,您的支持将鼓励我继续创作!