速记:SFDC 2016 - 网易蜂巢 刘超 《基于容器和微服务加快迭代速度实践》.docxVIP

速记:SFDC 2016 - 网易蜂巢 刘超 《基于容器和微服务加快迭代速度实践》.docx

  1. 1、本文档共7页,可阅读全部内容。
  2. 2、有哪些信誉好的足球投注网站(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。
  3. 3、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  4. 4、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  5. 5、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  6. 6、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  7. 7、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  8. 8、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
会议主题:SegmentFault2016开发者大会--杭州站 会议时间:2016年12月10日 9:00 会场主持人:SegmentFault 联合创始人兼CEO 高阳 议题:《基于容器和微服务加快迭代速度实践》 讲师:网易蜂巢 刘超 刘超:谢谢大家。刚刚主持人介绍网易蜂巢跟开发者密切相关的平台,网易蜂巢的发布会的时候,丁磊说网易蜂巢的目的是解放大多数的开发者,我今天是两个关键字,一个是容器,一个是微服务,我是觉得这两样东西,尤其是技术和微服务的概念,必将使得我们整个开发流程迭代的速度开发的便捷性都会极大的提升。我不知道在座有多少用过容器的。说明容器已经相对比较流行了。 这是我的一个个人介绍,我爱代码,爱开源,特别喜欢参与读开源的代码,在容器这个社区我是OPen dc/os社区贡献者。这是整个网易蜂巢的里程,网易蜂巢也是从基于虚拟机的私有云平台慢慢变到基于容器的一个公有云平台的这么一个转换。我们的转换包含4个方面,一个是平台层,一个是应用层,对于平台层,我们基于虚拟机到容器的转化,我们发现使用的容器之后,对整个迭代和整个环境的管理带来极大的便捷性,但是有容器跟虚拟机不一样。如果应用容器,我们对应用有一定的关注,我们对应用层做一定的微服务化,对于流程或者是项目的管理,我们也是需要开启这样一种DevOps的方式,就是把原来隔离的,就是在流程的两端拉到一块,我们最后在自己应用过程当中,已经非常成熟了,比如说,我们支撑很多的1级的产品线,然后我们才开始把容器私有云搬到公有云,服务我们所有的开发者。 这是网易蜂巢上面部署大规模的应用,我们95%以上的这个应用都在蜂巢平台上面,最早的邮箱,就是整个互联网的运用,比如说,云音乐,考拉,网易云课堂都是在网易蜂巢平台上面。我们的网络云音乐相对起步比较晚,现在积累相当庞大数量的用户。这是我们私有云平台的这么一个架构,私有员平台实现这些弹性,无论是内部的系统和外部的系统我们是五星级的机房,所有的存储都是SSD。我们做了各方面的优化,使我们的虚拟机的启动速度达到秒极,网络虚拟化实现open switch ,filter vxlan。因为从网易一开始的数据库缓冲服务和对象存储都是非常重要的,无论是邮箱还是笔记都是关系到数据库的应用,对象存储和缓冲的应用。 我们有自己定制的MYSQL的核心分支,主从切换数据零丢失,提供健康检查和SQL优化工具,缓存服务,主从热确,跨可用域部署。虚拟机的部署方式,对于里面的应用,如果说你的应用比较少的话,你可以去手工做这样的部署,应用量比较大,或者是划分的服务比较多,这个时候利用到自动化部署的工具,之所以利用到这个工具pupper chef ansible,我们双十一到来,原来有10台机器,现在要扩大到20台机器,另外的10台的机器没有用,就是需要人工部署,整个扩展的数据达不到敏捷性的要求,这个时候需要脚本来做这个事情。 应用层架构雏形,比较大的就是电商,对于互联网+应用来说,就是快速上线和验证,大家采取一种集约化单体的方式,比如说,对于电商一开始就是大家能够想到的,就是三个方面,一个是说商户把商品放上来,然后就是用户下单,然后就是第三方支付,一开始团队比较少,不至于说把价架构设置非常的复杂,到时候我们产品做出来,时间窗口已经过去,对于这种应用的好处就是比较容易开发,也是比较容易测试,部署也是比较容易部署,运维起来每次替换一下,基本上整个应用都可以更新,所以说,在关键验证的阶段这种架构没有什么问题。慢慢随着业务的发展,其实,你的整个应用的架构就会变得越来越复杂。 这个时候有喜有忧,喜就是业务的飞快的发展,用户量增长,这个时候功能越来越完善,对于用户来说要不要推荐一些活动,要不给一些积分,对于商户来说管理它的供应商和物流,对于商品来说,是不是需要运营,对于支付来说,是不是要对账或者是多个第三个的支付,架构比较复杂之后,就是便捷性突然都没有了。所遭遇的瓶颈就是服务器的部署,就是虚拟机这种状态的话,基本上就是说,你每次开启一个机器你都要一层一层往上去部署这个东西。另外一个就是数据库,一般这种应用都是非常依赖于后面的一个单体链的数据库,数据库的查询非常慢,一开始没有用缓冲,你数据库的查询会变成瓶颈。 无论是高峰期,还是低峰期,响应的速度比较慢,要么就是整理处理的流程非常慢,当整个应用非常非常复杂的时候,你发现整个功能的迭代速度慢下来,无论是改一个什么东西,你都需要跟很多人商量,我能不能改,会不会影响到您。你忘记测试一个东西,本来这个模块跟我没有关系,我改了一个东西这个模块不能用,这样会导致整个迭代速度有问题,如果架构上面不能满足的话,你需要项目的流程来做这个事情。 当然做的过程当中就是要进行应用架构的改造,就是应用架构的改

文档评论(0)

159****3685 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档