微服务中台技术栈选型~SpringCloud or K8s?

Building Microservices Platfrom ~ SpringCloud or K8s?

Posted by     "杨波" on Sunday, August 18, 2019

TOC

前言

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

什么是中台架构?

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

  • 第一层(最底层)是基础设施服务层 IaaS(Infrastructure as a Service),负责计算、网络、存储、监控、发布、机房和数据中心等基础设施。
  • 第二层是技术平台服务层 TPaaS(Technical Platform as a Service),负责中间件、大数据等基础服务和研发工具链等。第一二层在阿里体系中统称为技术中台。
  • 第三层是共享业务服务层 BPaaS 层(Business Platform as a Service),是阿里多年研发运营沉淀下来的商业能力模块(包括用户,商品,店铺和营销等等),被抽象封装成公共服务,供上层调用和集成,阿里把该层也称为业务中台。
  • 第四层(最上层)是业务前台层,按照不同业务线(淘宝、天猫和聚划算等)划分,再根据不同用户体验渠道(PC,无线和第三方接入等)构建不同的用户接口层。

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

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

航母平台化作战

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

ebay arch

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

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

ppdai platform

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

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

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

common concerns

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

  1. 配置管理:对微服务应用的可变参数进行配置。这些参数可以是启动期一次性配置的,例如数据库连接字符串,也可以是运行期动态配置的,例如调整缓存 TTL 过期时间,业务促销限购数量等。
  2. 服务发现和负载均衡:服务分布在不同的节点上,服务之间要相互调用,首先要定位找到对方,这个就是服务发现,它是微服务架构的基本问题。另外,服务一般以多实例方式部署,调用方需要以某种负载均衡策略去访问目标服务实例。
  3. 弹性和容错:分布式微服务通过网络互联,网络有可能不稳定,服务实例有可能延迟、出错甚至宕机,微服务系统必须具备弹性和容错能力,才能保障服务质量和用户体验。
  4. API 管理:这里主要指微服务系统对外暴露 API,一般通过 API 网关进行管理。网关是微服务的大门,需要支持反向路由、安全鉴权、日志监控和限流容错等基本功能,高级的网关要支持 A/B、蓝绿和灰度测试等高级功能。
  5. 服务安全:用户访问微服务首先需要认证,对某些敏感的服务进行操作还需要鉴权,服务之间调用也需要一定的权限管控。
  6. 日志监控:服务访问日志需要集中进行采集、存储和分析,方便后续进一步分析微服务性能,甚至是用户行为。
  7. Metrics 监控:对微服务的调用需要进行 Metrics 埋点监控。Metrics 监控既可以对服务性能(调用量、延迟、错误数)等进行监控,也可以对重要业务指标(如登录数、下单数等)进行监控。
  8. 调用链监控:分布式微服务之间的依赖关系错综复杂,通过调用链监控能够实时掌握微服务之间的依赖关系,服务之间调用的性能,出现问题时能够通过分析调用链及时排障。
  9. 调度和发布:微服务最终需要发布到生产环境中,目前推荐的微服务交付手段是容器云环境,容器云需要支持自动的容器资源调度和发布,高级的需要支持滚动(rolling update)、蓝绿(blue-green)等发布机制。
  10. 自愈和自动伸缩:云环境中的节点实例有可能宕机或漂移,网络可能随机不稳定,微服务平台需要有自动侦测问题和自动恢复的能力,这个就是自愈(self-healing)能力。另外,用户流量可能会突发骤增,理想情况下,微服务平台需要能根据用户流量的变化自动伸缩(auto-scaling),节省硬件资源同时又不影响用户体验。

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

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

Spring Cloud 和 Kubernetes 横向比对

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

sc_vs_k8s_1

  1. 服务发现和 LB:服务发现和 LB 是微服务基本问题,两家都给出了解决方案。SpringCloud 的服务发现主要引用 Netflix 的 Eureka,配合使用 Ribbon 实现客户端发现和软负载。K8s 则直接在平台层解决这个问题,它直接在平台中引入了 Service 这个抽象概念,屏蔽了底层服务发现和负载均衡细节,让应用开发和服务框架都不需要关心这层细节。
  2. API 网关:这层 SpringCloud 主要引用 Netflix 的 Zuul 网关,它是经过 Netflix 大流量考验的一个成熟产品。在 K8s 体系中,和网关对应的概念叫 Ingress,它定义了一些规范,具体可以采用各种实现,例如 Nginx、Envoy 或者 Traefik 等,都可以做 Ingress。
  3. 配置管理:这块 SpringCloud 有 Spring Cloud Config 对应产品,实现比较简单,后端基于 git 进行配置管理。K8s 则在平台层内置支持 ConfigMaps/Secrets 等配置机制,配置可以通过环境变量注入容器中,也可以挂载到容器文件系统中。
  4. 限流容错:这块 SpringCloud 支持 Netflix 开源的 Hystrix 容错限流组件,Hystrix 在 Netflix 平台稳定性方面发挥了巨大作用,它已经成为业界限流熔断的一个标配。K8s 平台内置支持健康检查(HealthCheck),启动就绪探针(Probe)等容错机制,如果需要细粒度流量控制,则需要引入 ServiceMesh 机制进行配合。
  5. 日志监控:这块两者都没有单独的开源产品,不过社区已经有 ELK(Elasticsearch/Logstash/Kibana)这样的成熟标配解决方案,两者都可以直接集成。K8s 推荐使用 Fluentd 进行日志采集。
  6. Metrics 监控:SpringCloud 支持 MicroMeter/Actuator 等机制,可以采集和暴露 Metrics 指标,方便对接 Prometheus 等监控告警系统。K8s 内置支持 MetricServer,可以采集 K8s 平台内部资源性能指标,方便对接 Promethues,如果要进一步监控应用层性能指标,可以引入 ServiceMesh 配合支持。
  7. 调用链监控:这块 SpringCloud 提供 Spring Cloud Sleuth,支持对接 Zipkin 调用链监控。K8s 推荐采用 Uber 开源的 Jaeger 进行调用链监控,也可以使用 Zipkin。

sc_vs_k8s_2

  1. 应用打包:SpringCloud 支持嵌入式容器+Uber Jar 方式打包,方便应用发布和运行。K8s 则直接支持容器镜像部署,它不关心容器内部的具体应用形式。K8s 还支持 Helm 这样的应用级打包标准,可以实现应用商店。
  2. 服务框架:Spring 本质上是一种 HTTP/REST 框架,比较松散简单,开发测试都友好。K8s 是一个平台,它是具体框架无关的,它只认容器,不同语言栈(Java/Go/Python/Node/Ruby 等等)的各种框架都可以住在 K8s 里头。具体语言栈无关是 K8s 区别于其它服务框架的最大亮点
  3. 发布和调度:这块 SpringCloud 没有单独考虑,而是交由运维去解决。K8s 平台本身重点解决的问题就是服务发布和容器调度。
  4. 自动伸缩和自愈:这块 SpringCloud 没有单独考虑,而是交由运维去解决。K8s 具备自动故障检测和自愈的能力,自动伸缩需要引入额外组件,完全实现有一定的技术门槛。
  5. 进程隔离:这块 SpringCloud 没有单独考虑。K8s 通过容器进行进程隔离,同时还引入了 Pod 进一步对服务进行隔离。
  6. 环境管理:这块 SpringCloud 没有单独考虑。K8s 内置支持 Namespace 进行逻辑隔离,可以实现多环境,各个环境可以单独配置认证授权机制。
  7. 资源配额:这块 SpringCloud 没有单独考虑。K8s 支持对 CPU/Memory 进行使用量限制,也支持 Namespace 级别的配额管理。
  8. 流量治理:主要指高级流量调度,A/B 和蓝绿部署等能力。这块 SpringCloud 没有专门方案。K8s 则需要引入 ServiceMesh 配合支持。

Spring Cloud 和 Kubernetes 优劣比对

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

sc_vs_k8s_3

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 运维的活外包给阿里云(开发商)。

在波波和极客时间合作的最新课程《SpringBoot 与 Kubernetes 云原生微服务实践》中,波波会结合具体案例Staffjoy 教学版开源项目,教大家如何基于 SpringBoot,架构、设计和实现面向云原生的微服务应用,并最终部署到阿里云 K8s 环境,欢迎感兴趣的同学关注学习。

promote

课程案例项目架构 staffjoy architecture

课程案例项目部署到阿里云 K8s 的部署架构 staffjoy aliyun k8s deployment

附录

  1. 阿里巴巴全面启动中台战略

  2. eBay Architecture

  3. 拍拍贷中台架构


comments powered by Disqus