【编者的话】Linker是一个有着创新基因的初创公司,核心团队来自惠普华为等知名公司。陈冉是Linker的CTO,在其带领下Linker创造性提出了
@aaS云计算3.0
的概念,并结合Mesos
和Docker
等开源技术开发出自己的云平台。下面是他在设计开发云平台过程中的经验分享。很高兴今天和大家分享,我先介绍下自己:
我叫陈冉,是Linker Networks的
首席技术官
和技术副总裁
。主要负责Linker的技术研发技术孵化和产品线推广。我和Linker团队运用云开源技术和自主研发,创新出Linker的新一代基于
Mesos
,K8S
和Docker
的领科云以及的产品线, 如LinkerLoot
,LinkerGear
,LinkerData
和LinkerOS
等。在此之前,我曾担任惠普云的首席架构师,首席云技术专家和领域专家。主要负责惠普
helion
技术的推广和宣传,为企业提供惠普云混合产品线的解决方案,并帮助客户建立,管理和消费云的完整流程和体系。曾经担任惠普公有云部门的首席架构师并完成惠普公有云产品的上线和产品化。早起我主要从事
OpenStack
和CloudFoundry
社区和工作。我们是面向业务的云平台。
我们公司成立于2011年,总部在Boston。现在在
北京
,南京
,台北
都有研发中心。当前移动业务的交付存在很多不便,而且对云的应用门槛比较高,不管是人力还是技能都有很多要求。
我们认为,传统的
IaaS
,PaaS
,SaaS
相对独立,所以是第一代,1.0。容器的交付方式是第二代,2.0,因为很多容器的依赖关系不存在,也不能支持业务快速交付和管理。
3.0应该是一种面向业务的交付模式,而已业务应该和IT剥离,并且松耦合,这样一个业务的IT可以被别的业务复用。
我们公司的领科云有两个业务,第一个是在线的云市场,第二个是以一种解决方案方式去呈现。
上面是我们的解决方案架构。其中,Linker SaaS/PaaS平台是基于Mesos/K8S的。Linker Marketplace是我们自己开发的。
下面是混合云的架构,可以是私有云,公有云或者其它。
我们的生态其实就是:我们用别人的资源。
就是
公有云
和私有云
还有流量
。因为我们认为,未来流量应该贯穿每个业务。然后,生态中,可以是开发人,也可以是消费者。也就是说,每个用户都具备两个属性,即
生产模版的人
,和消费模版的人
。总结来说,就是
云服务的淘宝
。移动用户生产出模版,就是发布成微服务了,用户有定价权利。我们是
Pay as you go
的方式。举例:用户A,生产出模板
A1
,发布到平台后,定价每小时8元。用户B看到后,认为不错,把自己模版和A1结合,变成B1
。这样用户C看到B1,并且order后,假设模板B1是10块,8块会每月一次自动给了用户A,剩下2块给B。这就是我们Reselling
概念。我们提供一站式交付方案,并且都是以容器的方式交付。所以用户有两种发式接入:
- 通过我们提供的LinkerOps,即CI/CD平台。即用户把自己的开发和测试环境搬到我们平台,那么每次会自动产生docker image,已及
dockerfile
模版。 - 用户自己开发完,在本地打成docker image,然后upload到我们的平台。
总的来说就是想`适配开发人员的使用习惯了。
ok,重点来了,上面的就是单独的SaaS/PaaS。我们的概念是:所有的业务都是有逻辑的,所以他们的架构就应该是下面的描述方式,就是
模版
了。如果发布,就是微服务。上面是我们的
core values
了。总结来说,就是业务和IT分离,可以被reuse,然后到运营。好了,说了那么多,LinkerOps/CI/CD是什么样呐:
其实这个CI/CD平台就是我们的一个模版,即微服务,都是基于Mesos的。
这个是我们设计好的LinkerOps,即Ci/CD 模版/微服务,大家可以一键部署了。
这个是我们大概架构,我们全部是
OpenSource
,现在也在和Apache foundation聊,打算后面全部开源。LinkGear
就是SaaS/PaaS平台产品的名字,LinkerLoot
是Linker Marketplace的产品名。最后,说一个真实案例:
这个是我们和台湾ITRI做的一个case。
原来状态:
- 全部手动安装
- 系统全部通过前台方式运行,需要在交互式命令行手动输入
- 全部单节点
面对面现场迁移至Docker后:
- 手动安装部分全部预安装到Docker Image
- 交互式命令行通过脚本方式执行
- Mysql启动Mysql Replication,实现高可用性
- SDN Controller变成模板,以后便可以一键生成
下面就是我们帮他们设计的模版:
他们会一键部署,弹性扩容(autoscaling)包括减少了运维的工作。
谢谢大家参与我的分享。
Q&A
Q1:请您详细解释下您对@aaS概念的理解,您说@aaS是3.0,那么您觉得它和2.0的CaaS以及1.0的IaaS、SaaS、PaaS有什么区别?Q2:请教下mesos和k8s你觉得他们各自有缺点在哪,以后两个产品发展的趋势如何?
2.0是容器比较独立,虽然有docker compose,但是还是没有很好的reuse起来。3.0主要面相业务的,有逻辑的。
Q3:我想了解一下领科云的营利模式,是卖资源还是卖服务?
mesos特点是多framework集成,多系统资源统一管理了。K8s就是为docker生的。各有优势了。感觉还是k8s比较有方向了,因为参与人群,公司都很多。
Q4:一键部署是从哪里开始一键,是从源码还是发布时间。如果是从源码,一些复杂应用的编译和配置生成是怎么解决的?
问题很好,都有的。我们用公有云的VM,我们切割成docker容器,所以挣一部分钱;还有我们设计基础模型和模版,谁用我们,都会把钱以Pay as you go的方式给我们。
Q5:另外问下移动生产者的模版你们负责审查吗,如何保证模版是安全的,没有恶意代码?
可以源码,也可以是docker image,或者dockerfile。CI/CD是源码,Service Onboard是docker image。复杂的都会被分割成模型,这样在复杂的应用都会被抽象,复用。前提是能够容器化。
Q6:这套架构上如何实现灰度发布?
是的,我们审查,审批后,才能发布的。我们会有test bed测试并且评估。
Q7:请问你们和数人云在产品上面有什么区别?你们的服务大多是面向企业的吧?有没有开发者相关的产品和服务?
每一个模版都会用HA设计属性,我们提供原子模版的无缝更新,主要看模版设计的。比如,设计中加入属性就是。
Q8:领科云是多数据中心方式吗?跨数据中心的数据一致性是怎么保证的?
个人想法,数人主要让客户提供主机访问,然后去安装Agent,然后部署mesos和marathon cluster。他们不是面向业务,也没有跨云的部署和管理,再有就是要对云、容器比较熟的人才能去玩。我们是面向业务,drag & Drop
的方式设计,发布,维护等。再有我们是跨平台
,我们来管理资源和底层,这样用户的使用门槛就低了。 而且我们有CI/CD。
Q9:k8s是如何与openstack结合的?
是的,我们有两种方式了,第一是用成熟的公有云,比如AWS和AliCloud。这样他们会提供DCs之间的稳定; 第二我们有自己的DCs,之间是通过tunnel
方式了。还有我们自己的网络解决方案,达到优选。比如flannel
。
Q10:用户程序容器化的工作是需要用户完成还是你们case by case 的提供解决方案,你们帮助用户容器化的工作模式是咋样的?
我们只是用Openstack的虚拟机资源,作为私有云的提供方
Q11:从图上看应用似乎是用nginx来作负载均衡的,那怎么实现服务的动态伸缩和服务发现的呢?
两种方式都可以
Q12:你们用openstack提供虚拟主机,那你们的docker容器是跑在公有云上还是私有云上的?你们部署自己的服务的时候遇见过坑吗?还有虚拟主机和容器的监控你们有做吗?
nginx是用户模版选择的负载均衡策略,而非平台指定的负载均衡策略,我们通过monitor
实现服务的自动伸缩和发现。
Q13:mysql这种服务,数据放哪儿?
公有云和私有云都有部署。私有云用openstack,公有云有aws、alicoud、青云,当然有很多的坑。虚拟机主机使用zabbix,容器使用cadvisor。
Q14:按照这个业务无关,如何做的不同业务间的隔离?在企业中这个很重要!
放到外部volume里,是在cephfs
下。
Q15:我看到你CloudFoundry和mesos都使用过,请问最终您基于什么考量最后选择了使用mesos作为云管理平台?
我们是通过容器,cpu,Mem隔离。网路通过OVS隔离,然后我们通过多租户对业务隔离。我们还有很多最佳实践,比如用户独享VM等。
Q16:你们怎么描述微服务间的依赖关系?比如a依赖b,b开放了多个端口,c依赖b的另一个端口?
Cloud foundry比较重了,我就是从Cloud foundry过来的。Mesos比较轻,然后利于异构环境资源统一管理,在有就是framework特征了。
Q17:容器间的网络用了什么方案?
依赖关系通过图形方式描述,ip和端口会作为参数传递给其他的模型。
Q18:请问贵公司的亮点(老A)在哪里?因为现在很多类似的公司,业务/技术栈都相差无几。
flannel和ovs
Q19:请教下,你们mesos和k8s是如何并存的?分别承担什么职责?
亮点有三:第一面向移动业务;第二是图形化设计业务系统;第三是流量贯穿模版和微服务,为终端客户考虑。 还有就是帮客户资源优选,起步低,入门快。我可以说现在我们是独一的。
Q20: 关于问题排查和解决,如果基础架构vm 存储等出现故障或者性能下降,由谁第一时间去响应和解决? 你们在这块会做哪些事情。 用户有选择iaas的灵活性么?
是的,我们同时孵化了。这个就是策略问题了。你懂的,现在是K8s做为framework,后期就会有很多问题。
Q21:对于主备数据节点的事务一致性是如何处理的?就是如果一个事务涉及到多个数据节点,如何保证数据的一致性?
如果是单独主机,则是服务提供方排查。如果是共享主机,则由linker排查。用户在12月30号有选择自有主机和iaas的灵活性。
如果是mysql则可以通过mysql cluster和mysql replication进行数据同步。
有疑问加站长微信联系(非本文作者)