构建微服务技术中台，SpringCloud和Kubernetes该如何选型？
前⾔
中台架构⼀词最近在技术圈内⽐较⽕，波波基于⾃⼰的经验和视⾓，也来凑个热闹聊聊什么是中台架构。中台架构实际由若⼲个层次组成，其中微服务技术中台是构建中台架构的重要组成部分。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)。下图总结这些公共技术关注点：
具体讲，这些关注点包括：
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所⽀持的功能点，做⼀个全⾯的横向⽐对：

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。