前言
中台架构一词最近在技术圈内比较火，波波基于自己的经验和视角，也来凑个热闹聊聊什么是中台架构。中台架构实际由若干个层次组成，其中微服务技术中台是构建中台架构的重要组成部分。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运维的活外包给阿里云(开发商)。
