公司新闻

EasyStack参加第七届数据技术嘉年华并发表主题演讲

Posted on 2020-02-02

微信图片_20171120133850


踏着最后一抹秋色,第七届数据技术嘉年华如约而至,11月17-18日在北京丽都皇冠假日酒店盛大召开,EasyStack副总裁周崇毅受邀出席大会并分享了主题演讲。以下为“Kubernetes与OpenStack融合支撑企业级微服务架构”演讲主要内容:


大家关注最新的Docker新闻会发现一个动态,Docker宣布在它的下一版本中将内置K8S的发行版,代表容器编排领域三条技术路线的竞争也就宣告到了尾声,基本上大家一致认定选择Kubernetes作为容器编排管理平台。在去年、前年参加容器的Meetup的时候,很多时候还要给大家解释为什么要用K8S,K8S和其他技术路线的比较,而到了今年,大家更多的是关注如何用好K8S,有了K8S平台之后怎么支撑上层的应用场景。前面一位讲师分享到,K8S的应用场景很多,比如微服务,用K8S做DevOps,还有TF这样的AI框架,还有区块链等等,这些都是K8S典型的应用场景。Kubernetes和IaaS平台不一样,它是面向应用的,搭建平台只是第一步,更关键的是怎么用这个平台。


微信图片_20171120115407

EasyStack 副总裁 周崇毅


我今天希望从微服务的角度讲讲我们怎么把K8S平台用好。我们公司是提供私有云解决方案的,最早我们提供基于OpenStack的云平台解决方案,从去年下半年开始基于K8S开发自己的容器云平台。相比于其他提供容器云平台的厂商,我们的特点是将Kubernetes和OpenStack进行融合,以支撑更广泛的应用场景,希望在今天的分享中给大家介绍这方面的工作。


我今天的分享分三部分:一是微服务架构的基本概念;二是怎么通过K8S支撑微服务架构;三是基于融合架构更好的落地微服务。

PART-1

微服务架构大家就关注几个问题:什么时候、哪个时间节点需要采取微服务架构,实施微服务架构的改造。我这边总结了几点,如果你当前所负责的应用系统面临这些瓶颈,那么你需要考虑微服务架构。


1、业务的复杂度已经增长到了,传统单体架构没有办法应对这个复杂度的时候,可以考虑采用微服务架构。右边是一张比较有说服力的图,比较了微服务架构和单体架构,随着业务的复杂度上升,它带来的生产力的比较,大家可以发现,其实在业务复杂度比较低的时候,咱们采用单体架构,其实它的生产力比微服务更高,随着咱们的业务复杂度越来越高之后,你采用微服务的优势相对比较明显。如果大家有过比较丰富的软件开发经验,在一个项目或者公司的初创期,大家一般不会一开始采用微服务架构,而是追求更快速的系统上线,通过单体架构进行应用的开发,采用短平快的方式,而发展到一定阶段之后,则开始考虑实施微服务架构。


2、第二个因素和人相关。如果大家看过《人类简史》就会发现,里面有一个结论,当一个组织的人数超过150人,那整个组织的沟通效率会随着人数的增长逐渐变低。对软件开发也是一样,如果一个项目非常大,做好几年甚至上十年,团队规模达到好几百人,你维护整个项目非常麻烦。


3、传统单体架构的问题,整个应用的维护随着时间往后越来越难。现在加入一个团队,它已经开发很多年一个大的应用,你会发现很头痛,怎么快速融入到整个项目的开发或者运维里面,它里面可能有数百万行代码,很可能让新人感觉无从下手。


4、传统的架构的升级和部署的难度相对来讲会更大一些,传统的架构,如果你要做一次服务的升级,可能需要将整个系统的服务停掉,从0开始,完整部署一个新版本的应用。


5、另外一个问题是应用迭代效率,如果迭代效率越来越低,比如从一两周发布一次,到几个月发布一次,且越来越慢,这时候你就会发现整个应用的迭代速度已经赶不上业务发展的效率,业务端提出的新需求无法得到响应。


6、传统的架构在应对互联网高并发、高压力的业务场景的时候面临比较大的瓶颈。如果采用传统架构应对高并发场景,在物理机时代,可能需要提前好几天开始准备,准备新的服务器,部署应用,部署负载均衡、数据库等,整个周期非常长,而且成本非常高。后来有了公有云平台或者OpenStack这种私有IaaS云平台,效率相对会高一些,但也只是把云主机、云存储和云网络部署出来,上层应用还是要自己部署,虽然能带来一定的弹性伸缩能力,但相对来讲效率还是不够高。


7、应用的容错性,单体应用的一个缺陷是,当其中有一个功能模块出现故障,很可能导致整个应用出现故障,无法实现良好的容错性和高可用性。


第二个问题,什么是微服务架构?相信大家了解微服务架构很多了。这边从技术角度和业务角度看微服务架构。微服务架构大家一致认为最早是美国的Netflix公司开始实践的,而微服务概念正式提出来是在2014年,Martin Flower发表论文将微服务的定义和特征进行了系统的总结和梳理。可以说,微服务架构是随着云计算的应用和发展,应运而生的一种软件设计服务的风格。技术角度它有什么特点?一是拆,用一组服务的方式构建一个系统。二是微服务组件是自包含,可以独立升级、独立部署、独立扩缩。相对来讲每个微服务都是独立的进程。这和原来单体架构的应用不一样,单体架构通常运行起来是一个进程,现在不一样,每个微服务都是单独的进程。第三,服务之间怎么进行调用?微服务更多的是采用轻量的交互机制,使用HTTP型的API进行交互。以上这些只是从技术方面讲微服务的特征,而更重要的从业务角度理解微服务。其中第一点是它的单一职责设计原则,一个微服务只负责一个单一职责。另外很重要的一点是需要从业务边界来确定微服务的边界,而不是从技术的角度来区分边界。


第三个问题,为什么要使用微服务架构?我这边列了重要的一点。


一个是解决刚才提到的问题,提升整个应用系统的迭代效率,与原来单体架构不同,采用微服务架构的应用,每个微服务都可以独立发布。现在有些大型互联网公司一个系统每天会进行上千次甚至上万次的发布,迭代的效率是非常高的。另外,升级带来的代价比较小,无需应用进行全部功能的完整升级,每个微服务组件做单独的升级。通过以上途径,提升迭代效率,更快速的响应需求变更。


二是弹性扩展,微服务采用松耦合设计,原来单体架构做弹性伸缩通常是整体进行弹性伸缩,而微服务可以单独做弹性伸缩。在在应用扩展时,仅需扩展有瓶颈的微服务,这样效率更高,而且节省资源。


三是容错能力,微服务因为本身是进程级别的隔离,且每个微服务是自治的,单个服务的异常通常不会导致整个系统的故障。


四是能丰富技术栈,每个微服务组件是自包含性的,每个微服务组件根据业务需求,都可以选用最合适的技术栈,比如不同的微服务可以用不同的语言,不同的开发框架,不同的后端数据库。针对不同的微服务,可以选择最合适的技术栈。


最后是和组织相关,这点也非常重要。康威定理提到,一个系统的架构跟组织的架构是对应的,也就是说,开发的应用系统的架构,是与组织架构对应的。原来传统的软件团队架构通常分为前端、后端、DBA等等,对应的话应用系统也分为这几个层次。而在微服务领域,会发生变化,每个微服务都由独立的团队开发和维护,从最初开发到测试到维护,负责它完整的生命周期。微服务团队规模不大,亚马逊有一个原则叫“两张披萨饼”,也就是说如果一个微服务的负责团队,两张披萨饼不够这个团队吃,则说明这个团队规模太大。控制好团队规模,可以提升整个沟通效率,而如果做得不好会产生负面的影响。


第四个问题,怎么做微服务的架构?有业务方面,有技术方面,还有组织结构方面的。


一般分三个步骤:


一是服务的建模,需要业务部门、架构部门和开发部门一起实现整个服务的建模,因此属于技术域和业务域。业界现在最受欢迎的方法就是领域驱动设计(DDD),这是非常有效的微服务建模方法。采用DDD主要是实现两个目的:1、如何合理的设计和拆分业务架构。2、保证所设计的业务架构和系统架构是统一的。


二是架构的设计和实现,属于技术域。业界现在有很多比较成熟的微服务开发框架,能够给你实现微服务架构带来很大的帮助。另外,需要选择合适的支撑平台,类型有以下几种,一是基于容器的,也就是基于Kubernetes、Docker技术,这也是目前用的比较多的;另外还有基于公有云平台、私有云OpenStack平台来做,还有基于面向应用的PaaS平台来做,像OpenShift、CloudFoundry。目前微服务开发框架和支撑平台两者之间的界限也在逐渐模糊,很明显的一个趋势就是,Kubernetes已经实现了很多原来微服务开发框架所实现的功能特性。


三是构建DevOps体系,属于组织结构域和技术域。组织结构相关的是团队文化需要DevOps化,团队要参与从软件开发到测试到运维整个环节里面来,而不是相互割裂。另外需要构建一整套DevOps所需要的工具链,比如大家经常用CI的工具,比如Jenkins,代码管理工具,GitLab、GitHub等等,现在开源的DevOps相关的工具非常多。

PART-2

Kubernetes的愿景是为构建基于微服务架构的大规模分布式系统提供标准化的框架。接下来给大家分享一下Kubernetes与微服务的关系,以及它如何支撑微服务。


这页片子里面列举了比较重要的点,例如,微服务的服务发现怎么做的?如何实现集中的配置中心,还有负载均衡,整个微服务的编排、升级、任务管理、日志管理、高可用怎么做的等等。基本上大部分支撑微服务架构所需的功能,Kubernetes都能提供,当然还有一些缺失,比如咱们经常用的断路器、服务网关等,相信Kubernetes后续会逐步完善其他方面的功能。


服务发现,实现原理很简单,基于服务端的服务发现原理,基于Kube Dns和service的机制做的。咱们要明确一点,微服务为什么需要服务发现的组件?因为微服务更多是基于云平台做的,有频繁的迭代和升级,有各种应用的发展,有一个问题是服务IP地址或者端口的标识会变化,传统架构大家固定不动,通过IP端口它就可以访问。有变化之后就需要引入服务发现的机制让我的服务之间能找到对方。


服务发现业界做的方式有几种:


第一个是使用比较成熟的云平台内置的服务发现组件,大型共有云平台有服务发现的组件。第二个是建服务发现的系统,常用的三种,Etcd、Zookeeper、Consul,另外使用微服务框架,比如SpringCloud Eureka。Kube-dns是属于第一种,云平台自带的服务发现组件。实现原理,K8S把service的名称注册到Kube-dns组件里面,它通过dns服务做映射,把service的名字和class做映射,如果Pod需要访问另外一个service,你就直接访问service name,不需要再找service的ClusterIP或者直接找POD的IP,都不需要,直接通过service name。具体实现的原理,Kube dns组件它是一个POD,里面有三个容器,它内置集成SkyDNS,做的事是监听K8S service,去更新整个DNS的记录。老版本里面集成了Etcd,新版本已经把Etcd去掉了。Dnsmasq为集群提供DNS查询服务,会将Kubedns中的记录读取到缓存中,提升整个DNS查询的效率。下面的exechealthz容器,作用是使用K8S健康检查探针来检查上面两个组件的健康状态。


集中式配置中心,现在为什么要实施微服务需要配置中心呢?


1、企业级应用配置管理确实比较复杂,配置信息的种类比较多,数据库的配置文件,还有中间件的配置文件,种类非常多。随着时间的积累,配置文件会非常多,版本也会非常多。


2、环境的种类也非常多,开发环境、测试环境、预生产环境、生产环境,开发环境也有很多套,基本上每套都有自己的配置文件。


3、如果采用微服务架构,服务的数量基本上是线性增长,配置文件的数量也是线性增长,你就需要有一个配置管理中心管理所有的配置文件。


4、更新配置文件的时候,相对来讲会比较烦琐,原来传统方式更新配置可能做的工作是整个应用都要重新构建、重新部署,重启一遍,现在构建微服务架构都要统一的配置中心。在Kubelet里面当然是采用大家提到的ConfigMap做配置管理,达到的是配置和容器分离,相当于有统一的配置管理中心,如果POD要使用配置文件,在生成POD的时候,就把yaml文件扩展进去。另外批量更新配置文件,相对来讲,如果我有一组POD使用的是同一个配置文件,只要在里面更新一下配置文件,自动把它同步到一组POD里面去。secret存储的是敏感信息,也可以归到配置中心功能里面去。


负载均衡,原来大家要自己实现,通过硬件的负载均衡或者软件的负载均衡做,K8S把负载均衡帮你做了。具体实践也比较简单,service后端会实现负载均衡,具体是Kube-Proxy组件做的,访问service的流量都会到后面一组POD里面去,默认采用轮巡的方式分配。这是POD和POD之间访问的负载均衡。大家肯定要做的外部负载均衡的实践,现在有三种方式做,一个是我自己建,通过软件或者硬件的方式,比如HAProxy、Nginx、F5,早期K8S都是第一种方式做。后来的K8S推出了Ingress,也可以基于Ingress做,还有使用云平台IaaS平台提供的负载均衡做,现在大的公有云平台肯定会提供负载均衡的服务,你可以做集成对接,比如OpenStack也可以提供Neutron LB做对接。这是负载均衡的实现。


下面的是弹性伸缩,这个场景非常多,大家比较容易理解,一个是定时性,周期性,我有一个定时的秒杀、推广,定时的抢票活动,其实比较推荐的还是提前规划,手动实施你的弹性伸缩。毕竟咱们通过底下自动的弹性伸缩的方式,是有监控指标的,肯定还是会有小段时间的延时,对秒杀活动,就算是1秒、2秒延时都会对整个系统带来影响,具体实现方式就是改ReplicaSet的副本数量。第二个是突发性的,这种事件没办法预测。基于HPA这个资源对象去做,它根据POD负载,它目前默认的是CPU,当然你可以自定义去做,比如QPS、TPS。应用行业很多,这只是列了一小部分,只要有大量2C的业务,有大量公众的业务,都会有这种高并发的需求。Kubernetes处理高并发场景也是它很强的优势。


容错性,其实主要是通过两方面做,一是故障自愈,容器异常时自动重启,二是Node节点宕机时,重新调度并启动容器。它检查整个容器是否运行正常,如果发现容器运行不正常,会重启整个容器,一般直接重启。Liveness探针,是检查容器是否处于运行状态,如检测到容器运行状态不正常,则Kubelet会杀掉容器,并根据设置的Restart Policy进行相应操作,比如重启。Readness探针,判断容器内服务器是否已正常工作。如果发现启动没有完成,它会把Pod IP从service的Endpoint中移除,不接受请求。还有自定义,可以判断执行一条命令,来判断容器健康状态。

<p style="box-sizing: border-box; margin-top: 0px; margin-bottom: 0px; padding: 0px; word-wrap: break-word; color: rgb(89, 87, 87); font-family: "Microsoft Yahei", "Hiragino Sans GB&quot

Posted in
咨询热线:400-100-3070

北京易捷思达科技发展有限公司:北京市海淀区西北旺东路10号院东区1号楼1层107-2号

南京子公司:江苏省南京市雨花台区软件大道168号润和创智中心B栋一楼西101

上海office:上海黄浦区西藏中路336号华旭大厦22楼2204

郑州分公司:河南省郑州市中原区西三环路大学科技园东区14号楼3层北户301

成都分公司:成都市高新区199号天府三街太平洋保险金融大厦A区8楼


邮编:100094


邮箱:

contact@easystack.cn (业务咨询)

partners@easystack.cn(合作伙伴咨询)

marketing@easystack.cn (市场合作)

training@easystack.cn (培训咨询)

hr@easystack.cn(招聘咨询)

Copyright © 2017 EasyStack Inc. All Rights Reserved. 京ICP备16000234号-1 京公网安备 11010802024994号