您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
   
 
     
   
 订阅
  捐助
构建微服务技术中台,SpringCloud和Kubernetes该如何选型?
 
作者昵称:架构师波波
 
190 次浏览 评价:  
 2021-1-27 
   
 
编辑推荐:
本文主要讲解了SpringCloud和K8s所支持的功能点(也就是它们所解决的微服务公共关注点),以及这两个产品的优劣和不足。
本文来自于CSDN,由火龙果软件Linda编辑、推荐。

前言

中台架构一词最近在技术圈内比较火,波波基于自己的经验和视角,也来凑个热闹聊聊什么是中台架构。中台架构实际由若干个层次组成,其中微服务技术中台是构建中台架构的重要组成部分。SpringCloud和Kubernetes,是目前互联网企业构建微服务技术中台所采用的主流技术栈,波波也会分析和比对这两个方案。Kubernetes平台封装了构建微服务技术中台所需的关键基础服务,它是波波推荐的,构建微服务技术中台的一个比较完备的基础方案。

什么是中台架构?

中台这个概念其实在国内最早是由阿里巴巴提出[参考附录1],原来主要是个业务和组织的概念。2015年,阿里提出构建DT时代的更灵活创新的“大中台、小前台”的所谓中台战略,强调组织业务和技术能力的抽象沉淀、模块化和重用,从而对各前台业务形成强力支撑,使得前台一线业务能够更敏捷、更快速适应瞬息万变的市场。从具体架构上讲,阿里的中台架构可以简化分为四个抽象层次,如下图所示,从下到上依次为:

第一层(最底层)是基础设施服务层IaaS(Infrastructure as a Service),负责计算、网络、存储、监控、发布、机房和数据中心等基础设施。

第二层是技术平台服务层TPaaS(Technical Platform as a Service),负责中间件、大数据等基础服务和研发工具链等。第一二层在阿里体系中统称为技术中台。

第三层是共享业务服务层BPaaS层(Business Platform as a Service),是阿里多年研发运营沉淀下来的商业能力模块(包括用户,商品,店铺和营销等等),被抽象封装成公共服务,供上层调用和集成,阿里把该层也称为业务中台。

第四层(最上层)是业务前台层,按照不同业务线(淘宝、天猫和聚划算等)划分,再根据不同用户体验渠道(PC,无线和第三方接入等)构建不同的用户接口层。

所谓“大中台、小前台”,就是要强化技术和业务中台的建设,把中台打扎实,才能支持并且赋能前台业务线快速迭代和创新。换句话说,有平台才有生态,只有把中台的土壤夯实,才能让前台的生态变得更加茂盛。

当一家互联网公司发展出中台以后,它的商业规模化能力就会比较强大。比方说阿里,原来它有淘宝、天猫和1688等核心业务线,之后它再扩展出其它业务线(比如阿里妈妈、菜鸟物流和阿里去啊等)就很快,因为它可以重用底层的这些技术和业务中台能力。相反,对于一些没有发展出中台的公司,它的商业拓展能力就会比较弱,每次拓展新的业务线可能需要从零构建这些底层的技术和业务能力,明显缓慢而且很累。这个可以和航母平台化作战体系做一个类比,我们都知道目前美国拥有世界上最庞大的航母战斗群,所以它的作战投射能力非常强,今天把航母拉到中东波斯湾,明天又拉到他国领海,很快能形成战斗威慑力,这就是大规模平台化作战的优势。

中台架构不仅阿里有,其它一些大型互联网公司也有,比方说eBay,下图是eBay的中台架构[参考附录2]。我曾经在eBay中国研发中心工作过,最早看到这张eBay中台架构图是在2008年左右,也就是说,在2008年前,eBay就已经具备了比较完善的中台架构。eBay的中台架构和阿里的大致是类似,也是分为对应的四个层次,只是各层的具体称谓有些区别。

阿里或者eBay的中台架构,实际也不是一开始设计出来的,而是不断演进出来的。这些公司都经历过不断重复造轮子和造烟囱的阶段,最终发现这样做不仅不可持续,更无法规模化,最终都演进到模块化和重用的中台架构,也就是说,中台架构是业务可持续发展和规模化的必然产物。

中台架构,可以作为互联网企业组织和系统架构的一个参考模型。构建类似阿里或eBay级别的中台门槛很高,资源和人力投入大,而且需要多年的沉淀和积累。但是我们可以学习借鉴阿里或者eBay的中台架构的思想,然后根据企业实际业务的规模、资源和投入的情况,构建轻量级的中台,来支持业务快速迭代和创新。下图是我在拍拍贷工作期间,根据拍拍贷的业务和组织情况,参考eBay的中台架构,设计的面向拍拍贷的轻量级中台架构[参考附录3]。

中台的抽象层次较高,和企业的战略、组织架构密切相关,是企业中高层和架构师需要理解和掌握的。对于一般的开发人员来说,其实并不需要急于去学习中台架构,简单了解即可。但是,对于一般的开发人员,如果后续想往架构或者管理方向发展,可以先从学习和掌握微服务技术中台开始。

微服务技术中台公共关注点

微服务架构的思想原本和中台架构没有直接关联,但是如果你有经验的话,你会发现微服务架构和中台架构是密切相关,并且可以相互映射的。同样以上图阿里的中台架构为例,中台架构的第一二层,可以对应称为微服务技术中台,而中台架构中的第三层,则可以对应称为微服务业务中台。对于微服务业务中台,我们并不展开,我们来聊聊微服务技术中台该如何构建?要回答这个问题,我们先要理解微服务技术中台到底要解决哪些技术问题,也就是所谓公共关注点(concerns)。下图总结这些公共技术关注点:

具体讲,这些关注点包括:

配置管理:对微服务应用的可变参数进行配置。这些参数可以是启动期一次性配置的,例如数据库连接字符串,也可以是运行期动态配置的,例如调整缓存TTL过期时间,业务促销限购数量等。

服务发现和负载均衡:服务分布在不同的节点上,服务之间要相互调用,首先要定位找到对方,这个就是服务发现,它是微服务架构的基本问题。另外,服务一般以多实例方式部署,调用方需要以某种负载均衡策略去访问目标服务实例。

弹性和容错:分布式微服务通过网络互联,网络有可能不稳定,服务实例有可能延迟、出错甚至宕机,微服务系统必须具备弹性和容错能力,才能保障服务质量和用户体验。

API管理:这里主要指微服务系统对外暴露API,一般通过API网关进行管理。网关是微服务的大门,需要支持反向路由、安全鉴权、日志监控和限流容错等基本功能,高级的网关要支持A/B、蓝绿和灰度测试等高级功能。

服务安全:用户访问微服务首先需要认证,对某些敏感的服务进行操作还需要鉴权,服务之间调用也需要一定的权限管控。

日志监控:服务访问日志需要集中进行采集、存储和分析,方便后续进一步分析微服务性能,甚至是用户行为。

Metrics监控:对微服务的调用需要进行Metrics埋点监控。Metrics监控既可以对服务性能(调用量、延迟、错误数)等进行监控,也可以对重要业务指标(如登录数、下单数等)进行监控。

调用链监控:分布式微服务之间的依赖关系错综复杂,通过调用链监控能够实时掌握微服务之间的依赖关系,服务之间调用的性能,出现问题时能够通过分析调用链及时排障。

调度和发布:微服务最终需要发布到生产环境中,目前推荐的微服务交付手段是容器云环境,容器云需要支持自动的容器资源调度和发布,高级的需要支持滚动(rolling update)、蓝绿(blue-green)等发布机制。

自愈和自动伸缩:云环境中的节点实例有可能宕机或漂移,网络可能随机不稳定,微服务平台需要有自动侦测问题和自动恢复的能力,这个就是自愈(self-healing)能力。另外,用户流量可能会突发骤增,理想情况下,微服务平台需要能根据用户流量的变化自动伸缩(auto-scaling),节省硬件资源同时又不影响用户体验。

关于上述公共关注点中的前面8个点,波波和极客时间合作的课程《微服务架构和实践160讲》,对架构原理和开源产品有深度剖析,欢迎有兴趣同学进一步学习。

如果把微服务的上述公共关注点抽象、封装和沉淀下来,最终产出的软件产品,就称为微服务开发框架/平台。SpringCloud和K8s,分别是Netflix(+Pivotal)和谷歌,两家公司各自演进、沉淀并开源贡献给社区的解决方案。

Spring Cloud和Kubernetes横向比对

前面我们讲到,SpringCloud和K8s,分别是Netflix和谷歌,针对微服务公共关注点给出的解,只不过它们两家的解法和侧重点有所不同。这里有两个表,通过这两个表,我们对SpringCloud vs K8s所支持的功能点,做一个全面的横向比对:

服务发现和LB:服务发现和LB是微服务基本问题,两家都给出了解决方案。SpringCloud的服务发现主要引用Netflix的Eureka,配合使用Ribbon实现客户端发现和软负载。K8s则直接在平台层解决这个问题,它直接在平台中引入了Service这个抽象概念,屏蔽了底层服务发现和负载均衡细节,让应用开发和服务框架都不需要关心这层细节。

API网关:这层SpringCloud主要引用Netflix的Zuul网关,它是经过Netflix大流量考验的一个成熟产品。在K8s体系中,和网关对应的概念叫Ingress,它定义了一些规范,具体可以采用各种实现,例如Nginx、Envoy或者Traefik等,都可以做Ingress。

配置管理:这块SpringCloud有Spring Cloud Config对应产品,实现比较简单,后端基于git进行配置管理。K8s则在平台层内置支持ConfigMaps/Secrets等配置机制,配置可以通过环境变量注入容器中,也可以挂载到容器文件系统中。

限流容错:这块SpringCloud支持Netflix开源的Hystrix容错限流组件,Hystrix在Netflix平台稳定性方面发挥了巨大作用,它已经成为业界限流熔断的一个标配。K8s平台内置支持健康检查(HealthCheck),启动就绪探针(Probe)等容错机制,如果需要细粒度流量控制,则需要引入ServiceMesh机制进行配合。

日志监控:这块两者都没有单独的开源产品,不过社区已经有ELK(Elasticsearch/Logstash/Kibana)这样的成熟标配解决方案,两者都可以直接集成。K8s推荐使用Fluentd进行日志采集。

Metrics监控:SpringCloud支持MicroMeter/Actuator等机制,可以采集和暴露Metrics指标,方便对接Prometheus等监控告警系统。K8s内置支持MetricServer,可以采集K8s平台内部资源性能指标,方便对接Promethues,如果要进一步监控应用层性能指标,可以引入ServiceMesh配合支持。

调用链监控:这块SpringCloud提供Spring Cloud Sleuth,支持对接Zipkin调用链监控。K8s推荐采用Uber开源的Jaeger进行调用链监控,也可以使用Zipkin。

应用打包:SpringCloud支持嵌入式容器+Uber Jar方式打包,方便应用发布和运行。K8s则直接支持容器镜像部署,它不关心容器内部的具体应用形式。K8s还支持Helm这样的应用级打包标准,可以实现应用商店。

服务框架:Spring本质上是一种HTTP/REST框架,比较松散简单,开发测试都友好。K8s是一个平台,它是具体框架无关的,它只认容器,不同语言栈(Java/Go/Python/Node/Ruby等等)的各种框架都可以住在K8s里头。具体语言栈无关是K8s区别于其它服务框架的最大亮点。

发布和调度:这块SpringCloud没有单独考虑,而是交由运维去解决。K8s平台本身重点解决的问题就是服务发布和容器调度。

自动伸缩和自愈:这块SpringCloud没有单独考虑,而是交由运维去解决。K8s具备自动故障检测和自愈的能力,自动伸缩需要引入额外组件,完全实现有一定的技术门槛。

进程隔离:这块SpringCloud没有单独考虑。K8s通过容器进行进程隔离,同时还引入了Pod进一步对服务进行隔离。

环境管理:这块SpringCloud没有单独考虑。K8s内置支持Namespace进行逻辑隔离,可以实现多环境,各个环境可以单独配置认证授权机制。

资源配额:这块SpringCloud没有单独考虑。K8s支持对CPU/Memory进行使用量限制,也支持Namespace级别的配额管理。

流量治理:主要指高级流量调度,A/B和蓝绿部署等能力。这块SpringCloud没有专门方案。K8s则需要引入ServiceMesh配合支持。

Spring Cloud和Kubernetes优劣比对

经过比对,大家应该对SpringCloud和K8s这两个产品的功能点,应该有比较全面的了解了。下面我们对这两个产品的优势和不足,再进行一个比对:

SpringCloud是Spring框架和NetflixOSS的融合的产物,它同时吸纳了两者的优势。Spring框架有超过十年历史,是开源界的一个传奇。Spring框架社区异常活跃,框架本身成熟灵活,开发者体验好是最大亮点,背后有Pivotal公司提供专业支持,不断完善和推陈出新。NetflixOSS是现代微服务架构大胆创新产物,同时也经历过Netflix大流量冲击洗礼。Netflix框架的一大亮点是抽象和组件化做的比较好,可以像搭积木一样灵活组装微服务基础设施,而且可以灵活替换。SpringCloud的不足主要是仅限于JVM语言栈,其它语言栈支持非常有限。另外,SpringBoot因为封装较多,运行起来比较吃资源,尤其是跑在容器里的时候。

K8s和SpringCloud的主要差异在于,它是从平台层解决微服务基础设施问题的,抽象层级更高,它一次性解决了服务自动化发布的难题,而且它做到具体服务框架无关,可以容纳各种语言栈框架。可以认为,SpringCloud仅解决了微服务基础设施的部分问题,而K8s则是一个完整的微服务基础设施解决方案,所以,K8s是构建微服务技术中台的推荐基础方案。K8s背后有谷歌支持,社区异常活跃,被认为是未来的数据中心操作系统,云原生应用的标配。K8s的不足是它是一个更偏向DevOps和运维的平台,比较重量复杂,技术门槛相对比较高,一般的中小公司可能hold不住。

简单做个比喻,SpringCloud是组件化的,如果比喻建房子的话,就是自己买建筑材料自己建房;K8s是平台,如果比喻建房子的话,就是开发商承建的商品房,用户购买后拎包入住即可。

我的建议

经过上面的比对,大家对SpringCloud和K8s所支持的功能点(也就是它们所解决的微服务公共关注点),以及这两个产品的优劣和不足,应该有进一步的理解了。那么我们到底该如何选择呢?这里我给出一些建议。

首先,这两个产品都有大规模成功落地案例,没有绝对的好坏。作为架构师,重要的是理解这些框架背后的SOA/微服务关注点,理解这些产品如何解决这些关注点,它们各自的优势和不足,然后根据企业实际上下文(发展阶段、业务、技术架构和团队等)综合考量。

在此基础上,波波会有自己的个人倾向,波波比较看重两点,一个是社区生态,毕竟随大流比走冷门要轻松很多,另外一个是对微服务公共关注点考虑的全面性,我不想自己再花费精力去解决自动化发布等繁琐的事情。综上,我比较倾向K8s平台+SpringBoot框架,这两个是目前社区的绝对主流,可以用如日中天来形容,K8s是针对微服务公共关注点最完备的解决方案,服务框架我倾向直接用SpringBoot,我不需要SpringCloud那套,因为它支持的功能K8s已经覆盖了很大部分。另外,考虑到K8s技术门槛和运维成本高,对于一般的中小公司,我不倾向自建K8s,而是建议直接采用公有云K8s(例如阿里云K8s),把K8s运维的活外包给阿里云(开发商)。

 
   
190 次浏览     评价: 订阅 捐助
相关文章

阻碍使用企业架构的原因及克服方法
世界级企业架构的行业挑战
企业架构和SOA架构的角色将融合
什么最适合您的组织?
相关文档

企业架构与ITIL
企业架构框架
Zachman企业架构框架简介
企业架构让SOA落地
相关课程

企业架构设计
软件架构案例分析和最佳实践
嵌入式软件架构设计—高级实践
企业级SOA架构实践
最新课程计划
 
最新文章
大数据平台下的数据治理
如何设计实时数据平台(技术篇)
大数据资产管理总体框架概述
Kafka架构和原理
ELK多种架构及优劣
最新课程
大数据平台搭建与高性能计算
大数据平台架构与应用实战
大数据系统运维
大数据分析与管理
Python及数据分析
更多...   
成功案例
某通信设备企业 Python数据分析与挖掘
某银行 人工智能+Python+大数据
北京 Python及数据分析
神龙汽车 大数据技术平台-Hadoop
中国电信 大数据时代与现代企业的数据化运营实践
更多...