混合云架构设计与实施中常见的坑(有彩蛋)

战学超 2019-09-19 10:14:00


大家好,我今天的分享内容跟企业云计算有关,因为并不太清楚各位的技术实力,所以呢,先奉上我之前做的一个比较全面一点的PPT。当然这个PPT现在属于半成品,不过涵盖了什么是云计算、云计算架构(包括整体架构和计算存储网络安全等)、微服务架构、DevOps、持续交付平台等内容,大家有兴趣的话,可以回头看一看。

 

链接:https://pan.baidu.com/s/1voIP5MkKHmL094PWnlWtWQ

提取码:fvfj

 

那我今天要跟大家讨论的是企业混合多云架构。主要包括三个内容:

 

  • 企业混合多云的渊源;

  • 企业混合多云架构简介;

  • 落地实施的一些经验和坑。

 

一、企业混合多云的渊源

 

首先是企业混合多云的渊源。可以看到这个云前面是有两个修饰词的:混合、多。为什么要“混合”,为什么要“多”,请听我一一白话:

 

1、混合云
 

 

首先是混合。混合云是指混合私有云、公有云、专有云(有时也称行业云)的排列组合,不同的组合有不同的适用场景。

 

这里私有云+公有云的场景还是蛮多的,尤其是一些大型传统企业,既有内部的信息系统,也有对外的营销系统。

 

这里说一下专有云,或称行业云:对外专有云情况如何我不太清楚,总觉得专有云是在国内特有,存在即合理,这也是实际情况决定其存在价值的,例如金融行业的大银行推出的公有云,外行业用的较少,金融行业的中小型银行用的可能性较大,这种我觉得是可以成为今天专有云的,类似这种的还有民航专有云、医疗专有云等等吧。

 

专有云也有其显著的优势,就是行业背景深厚,与企业自身业务贴合度极高。转过头来继续混合的解释。以民航航空公司为例吧,既有内部使用的办公系统、生产系统、财务系统等,又有外部售票的官网系统,同时呢还有与民航局、机场等专线互联的专业系统,那这就是一个典型的混合云场景。

 

其实呢,替代混合云的传统方式也是有的:自建机房+专线,至于为什么要逐渐推广混合云,这里不再过多赘述。存在即合理,潮流即风向,其实内部原因也是促使推广落地的重要原因之一。那关于混合就介绍到这里。

 

2、多云
 

 

接下来是多。加上多个人感觉这应该是在18年下半年,特别是年底的时候,各大厂家、专家集中热谈的关于云的一个方向,及多云平台。还是那个话,存在即合理,这也是现状。这个可以从18年开始说起,18年是公有云的一个多灾多难的年份,简单梳理了几个18年的公有云事故,有如下:

 

  • 雷击损害微软美国中南区数据中心,Azure宕机18个小时;

  • 腾讯云服务故障致部分网站无法访问:运营商光缆中断;

  • 阿里云服务大规模故障:运维操作失误;

  • YouTube频道页面宕机5个小时 官方晚上8点宣布恢复;

  • 谷歌网络服务宕机,却让中国电信背锅。

 

参考链接:https://mp.weixin.qq.com/s/eM_z6INqHVDQfDJYNqDedA

 

其实就这19年的上半年阿里云得有3次部分停机(其实今天上午登录阿里云的控制台的时候也是不稳定,部分朋友反馈登录不进去)、AWS北京地区一次大规模停机等,公有云虽然可用性很高N个9,但是爆出来的故障也真不少,就这种现状,你敢将所有系统all in 公有云?你敢公有云只选择only one ?

 

本着不能把鸡蛋都放在一个篮子里,多云就自然而然的被提出来了,于是基于多云的MSP云管平台也逐渐取代CMP成为专家大牛口中的新宠。

 

二、企业混合多云架构简介

 

综上,混合多云是趋势也是企业负责人在进行云架构的时候要着重考虑的。OK,那方向有了,怎么搞起来撒?先呈现一幅图,说实话,这个图还蛮难画的,直到现在也觉得非常不完美,哎,谁让咋不是学美术的呢,就知道程序员PPT三原色:蓝灰绿。虽不完美,将就着看:

 

 

对于这个架构图,我就不过多解释了,大家也应该看过太多太多类似的或是相似的,简要以下几点:

 

1、云安全的解决方案
 

 

多云管理是在底层基础资源层,通过建立基础资源池整合内部私有云、外部公有云和行业云的资源形成统一的计算资源池、存储资源池、网络资源池和安全资源池,安全资源池还是比较费劲一些,但是也不难,现在方案都很成熟,主要就是一个引流+客户端。这里奉上一个安全厂商提供的云安全的解决方案,供参考:

 

 

2、云计算层的核心
 

 

简单来说,IaaS层是以资源为核心的;而PaaS层则是以应用为核心。那SaaS呢?个人感觉SaaS是以用户为核心的。IaaS纳管多个平台的资源,这个现在来讲不难,大多厂商是可以实现的,并且基于资源池建立的服务目录如虚拟机创建、变更、常用服务器创建等。

 

3、PaaS层以应用为核心
 

 

3、PaaS层是以应用为核心的,那怎么以应用为核心呢?两点:一是基于devops的持续交付平台;另一点就是服务目录,这跟IaaS层的服务目录有一定重合性,但这无所谓,对于云服务层只有一套服务目录。

 

有的企业喜欢建立基于容器的云平台,我的观点呢,容器始终是容器,更过的是给应用APP使用的,最典型的就是容器里面部署Tomcat或是微服务的JAR包。

 

在传统行业中,还是有很多容器不适应或是正在适应的应用,数据库跑在容器中也是一个挑战,故在我目前所设计的方案中,容器只是运行web应用,更多的是配合建立持续交付平台,这包括以下组件:svn/git、Jenkins、maven+nexus、sonarqube、jmeter、selenium、nginx、tomcat、docker、harbor等等。

 

建立持续交付平台,加快交付速度和提高交付质量,使整个云平台更加活跃。至于服务目录,则为云平台的重点,服务目录往简单了说就是虚拟化中的template,容器化中的镜像,目的是为了标准、便捷。

 

4、实施中的问题
 

 

SaaS平台需要更多的研发,围绕的是用户所需。常用的SaaS应用如大数据平台、日志管理平台、OA、财务等,可供各租户公用而又可通过用户区分的场景。

 

OK,在回到混合多云,其实实现基于混合多云架构还是蛮复杂的,因为有不少问题,包括规划设计时的问题、落地实施中的问题以及运维运营时的问题,很遗憾,我们目前还未完全建立,比较棘手的问题有:

 

1、数据存放问题

 

混合多云意味着你的数据可能要存放在3个地方:私有云和两个及以上的公有云,甚至还有混合云。数据怎么存放,数据之间怎么同步,这是个头疼的问题。多数据中心还有存储层面的数据同步,但是多云环境,存储层面的数据同步似乎不太管用。建议还是在应用层面和数据库层面进行同步,既然涉及到数据同步,那么网络问题就紧接着来了。

 

2、网络专线问题

 

网络在整个云计算平台中是个最重要、最复杂的部分,不接受任何反驳,不管是云平台内部还是多云之间。这需要花费点功夫的。由于专线的不稳定性和延迟,要求我们的系统架构在设计的时候,要求能够容错,能够承受不同步、延迟带来的问题,架构上的优化调整也是不得不面对的。这个又是系统架构的问题,详细可以参考我的一个课程,不过那个课程没有从跨区域网络延迟方面剖析架构的设计,改天可以写一个专题。

 

3、流量调配问题

 

多云环境涉及到用户访问的流量引流问题,这个需要在最前端GSLB根据实际业务情况进行引流配置。

 

4、安全性问题

 

安全是企业上云不得不面临的问题。在17年以前吧,企业上云,安全是个首要面对的问题,因为企业上云之后数据的安全责任不好界定,但是在网络安全法和等保2.0的实施之后,企业上云之后的安全责任界定有了明确的说明:

 

 

三、落地实施的一些经验和坑

 

以上是混合多云架构的一些介绍,接下来是最后,结合我们公司上云实施过程中的经验和坑,给大家分享几个点:

 

1、开源与商业
 

 

关于开源与商业,说句容易挨板砖的话,二线城市的大部分公司不太适合使用开源技术搭建企业云平台。虽然OpenStack很火,资料和案例很多很多。但是人员是最大的问题。招人难,留人难,人一走,事要完。

 

深有体会,我们之前就是使用OpenStack自己搭建的测试环境,说实话一开始搞起来,还是蛮兴奋的。但是随着时间的推移,系统的不稳定、操作不便利、界面不美观、性能较低下等等问题爆出来,运维起来逐渐感到很疲惫。

 

2、标准化的重要性
 

 

关于标准化的重要性,这个不用多说,标准化的缺失,将会对后续的自动化、智能化带来很多麻烦。同时也会带来不稳定、不安全的隐患。

 

3、贸易战
 

 

有的时候需要考虑点贸易战,如华为等,这个今年是真有体会啊。我们前几天就收到过惠普停止供应备件的邮件。所以在进行选型的时候,还是得多多注意的啊。选国产也有头疼的时候,具体不太方便说的某著名品牌,当时也面临着供不上货的问题(硬件)。

 

>>>>

直播回放

 

https://m.qlchat.com/topic/details?topicId=2000005767147604

彩蛋来了



在本文微信订阅号(dbaplus)评论区留下足以引起共鸣的真知灼见,小编将在本文发布后的隔天中午12点根据留言精彩程度选出1位幸运读者,送出以下好书一本~

注:同一月份里,已获赠者将不可重复拿书。

 

特别鸣谢华章科技为活动提供图书赞助。

活动预告