微服务中台落地 中台误区

小结：

一、

微服务中台不是

/1堆砌技术组件就是中台

/2拥有服务治理就是中台

/3增长部分业务功能就是中台

/4Cloud Native 就是中台

 

https://mp.weixin.qq.com/s/uuaraAWReOYeZuEJiLs9dw

企业微服务中台落地实践和思想之我见

From  朱德明 InfoQ 4/3

微服务和中台是这几年很是时髦随处可见的词，最早在一批互联网企业中开始谈论和建设，并逐渐的蔓延至一些传统企业和传统的 IT 部门，以致于如今在构建信息系统时，不少企业都在说要建一个中台，但究竟要建成什么样还不是很清楚或者说有些迷茫，笔者在微服务出来的时候也不是特别的明白到底如何建好一个企业中台，只是跟着感受走，随着主导和经历多个项目后，有了本身的部分认识，能够与你们在此分享。

咱们认为中台的意义应该是什么，不管是技术中台，业务中台仍是数据中台，我想它应该是为业务和组织而生，为能更加快速敏捷的响应业务的变化，给公司带来效能上的提高，价值上的提高，创新能力的加强，进而还能促进人才和组织的优化，这是中台所存在的意义。

首先在不知道微服务中台是什么样的时候，它必定不是这几个样子：

 1. 堆砌技术组件就是中台

 

 

只堆技术组件，微服务中台或者说企业中台只包含经常使用的技术组件，好比使用 spring cloud 微服务框架，再加上 MQ,Redis, quartz,nginx,activity,servicemesh,docker 几个组件以后认为这个就是企业的中台，要什么技术能力拿过去用便可，说法其实并无错，只是站的角度不一样，确实是能力的抽象，封装和开放，但并非纯粹的堆砌技术组件。

 2. 拥有服务治理就是中台

 

为 spring cloud 这样微服务开发框架加强了服务治理的能力，而后在绑定上业务就是技术中台或者中台。

这样的见解不是彻底正确，这只能表明在技术的基础底座和支撑上前进了一步，还远远不够。

 3. 增长部分业务功能就是中台

对老系统增长新功能确实是构建中台道路上必须经历的一件事，但若是只是单纯的从增长新功能角度出发而不是为了能力组件化，服务化，封装和开放，协同做战的思想去建设，那么只是给老系统增长负担而不是减负。

 4. Cloud Native 就是中台

Cloud Native 是目前比较火的领域，不少企业认为作了微服务，容器，DevOps 就已经构成了中台体系，这也是比较片面的见解，只能说有了这三大块，对于构建中台体系有了一个很好的基座，但真正的中台还并未出现。

 

@/先从技术中台方面来探讨一下技术中台的落地建设，后续咱们再来讨论业务中台。/

刚刚上面咱们认为中台应该不是什么样子，那到底中台应该是什么样子，有什么价值，就如咱们上面所说，它必定是为业务和组织而生，你能够从不少角度去解读它，本篇文章咱们结合在新项目建设中，咱们先从技术中台方面来探讨一下技术中台的落地建设，后续咱们再来讨论业务中台。

 技术中台

以下图，我先把技术中台分为这几部分，固然它包含很大的范围和其余的角度，但咱们能够根据这几点展现出部分技术中台思想：

1. 容器平台，虚拟机

2. 微服务框架 (分布式服务框架) && 微服务管理控制台

3. 技术组件

4. 公共基础服务和技术服务

5. DevOps&&AIOps

6. 效能

 

  容器云，虚拟机

虚拟机和应用上云对 Iaas 厂商有了更高的要求，不只在稳定性和可用性方面要有出色的表现，更加应该在易用性和便捷性方面展现出强大的功能，这方面必须能提供具备丰富功能和配置的 UI 界面，它有助于咱们在 Iaas 的配置和运维层面减小工做量，优化人员配置，提升咱们对 Iaas 的掌控能力，这是一个有和优的问题，另外对于厂商的选择和团队的选择，必定是要能及时响应的。

虚拟机和应用上云对 Iaas 厂商有了更高的要求，不只在稳定性和可用性方面要有出色的表现，更加应该在易用性和便捷性方面展现出强大的功能，这方面必须能提供具备丰富功能和配置的 UI 界面，它有助于咱们在 Iaas 的配置和运维层面减小工做量，优化人员配置，提升咱们对 Iaas 的掌控能力，这是一个有和优的问题，另外对于厂商的选择和团队的选择，必定是要能及时响应的。

对于采用了容器的厂商，起码要在这几方面须要作好，集群的管理和调度，网络方案，服务编排，日志方案，存储方案，应用和服务的管理，容器的监控和告警，镜像仓库的管理，镜像的打包和构建，用户的权限，优秀的 UI 操做界面等等。

一样的对于容器，若是它是一个优秀的产品，那它还应该是这样的：

1. 充分开放的和可扩展的接口。

2. 能够和多个产品进行对应快速，如微服务产品。

3. 丰富和体验方便的 UI， 高度集成功能的 UI，可见便可得。

4. 充分的对接 DevOps 文化，丰富的 CICD 流程，镜像一键打包。

5. 容器应用与非容器应用通讯，跨集群通讯。

6. 优秀的监控体系。

7. 等等。

这部分的能力是让整个技术中台有一个好的基础设施层支撑，能快速的进行应用的部署和交付，出问题时能迅速定位和恢复，下降 MTTR, 并能充分的利用现有资源进行合理的分配，让技术和业务下降耦合，划分出业务实现者与技术支撑的 BC，关注各自的领域，因此你须要一个很是靠谱和好用的底层支撑。

 微服务框架 (分布式服务框架)  && 微服务管理控制台

对于传统老应用而言，它多是传统的单体应用，整个系统的功能都融合在一块儿。它们在迎接需求剧烈变化和传统开发迭代方面遇到了瓶颈，那么在转型时就会考虑服务化的架构，在作服务化架构时，咱们就须要一个完整而健全的分布式服务化框架来帮助咱们，诸如 Pivotal 的 Spring Cloud 框架。

但这里要提醒的是，若是你要打造一款真正的技术中台，我认为一个纯粹的 Spring Cloud 的框架是很是不够的，它只能说是一款开发框架，而不是一个真正的微服务产品，不能为业务开发提供充足的保障。那么究竟什么是一款完整的微服务产品呢? 我起码认为它应该拥有这两个基本的能力：

第一，要拥有微服务框架技术能力。

第二，要拥有完整的服务治理能力，拥有应用全生命周期的管理能力。

第一部分是基础的微服务框架能力，这里面应当包括：服务注册，服务发现，负载均衡，熔断保护，服务路由，服务通讯等。

第二部分是拥有完整的服务治理能力，这里面的内容比较多，通常会有： 服务的管理，可视化治理界面，服务构建发布，分布式事务，流量控制，监控告警，服务契约，链路跟踪，灰度发布，服务降级等等。

微服务产品这一节能够单独拿出来讲，这里就不过多讨论，其实好的产品应该还要有其余部分考量，如对接各类其余技术组件和其余产品的能力。

业界的微服务产品有不少，这里列几款：

• 腾讯 TSF 产品，Tars 产品。

• 阿里的 Dubbo, EDAS 系列。

• 华为的 ServiceComb，ServiceStage 系列。

• 蚂蚁金服 SOFA 系列。

• Pivotal 的 Cloud Foundary。

• 微软的 Service Fabric。

• 网易的轻舟微服务。

这部分的内容是咱们技术中台的基座，它能够帮咱们解决大部分在开发测试，网络通讯，分布式等方面的难题，也是咱们在构建微服务应用，技术组件，公共支撑等方面的基础，加上完整的微服务治理能力，能充分帮咱们解决在微服务拆分后的管理和运维问题，因此这部份内容是至关重要的。

 技术组件

咱们这里探讨的是中台能力不是只堆砌技术组件，不是缺消息队列和定时任务调度框架就装一个 RabbitMQ 和 Quartz，而后就抛给业务开发去使用，咱们而是思考如何让业务开发更好更快速地上手使用，如何让多个项目组使用时保证组件的稳定和可用性。好比项目须要使用某个技术组件，咱们能够经历如下几个步骤：

1. 写一个文档，告诉开发须要哪些依赖，引用什么样的配置便可。

2. 发现每一个人都要这样很麻烦，咱们即把依赖引入父工程或公共依赖。

3. 发现每一个人还须要配各类配置后，咱们可剩下不能减小的配置，如服务名，其余的都放在远程配置中心或环境变量或其余地方。

4. 增长 UI 可视化能力，可视化管理能力。

5. 标准化，微服务化，业务域、系统级、公司级别统一微服务，多租户能力，如给每一个应用分配权限，单独的进行数据操做，维护，管理。

6. 发现需求，优化迭代。

一般通常的只是作 1,2,3 点，稍微好点的能够会增长第四点，若是真正的落地技术中台，应该在第四点，第五点和第六点发力，进行能力的抽象，进而造成标准化的能力，还能很是快速的提供给业务和其余技术部门使用，维护成本也低，这才是真正能为团队和业务带来价值的地方，也是提升研发效能和组织效率的途径，这三点就须要单独去开发和建设了。

这部分的能力就是让咱们开发、测试、运维人员能快速的使用这些技术组件帮助咱们解决特定问题，而且利用这些能力开发出公共微服务，提供给公司使用。

 公共基础服务和技术服务

对于公共基础服务和技术服务其实包含的东西也不少，只要能抽取出公共能力的服务或技术，均可以单独拿出来进行操做：

• 公共基础服务：用户权限服务，业务配置服务, 通知服务，数据分析服务等。

• 技术服务：缓存服务，分布式 ID 服务，消息队列，分布式任务调度服务等。

好比权限服务，那么是否考虑整个公司或者大的业务域是一套权限中心，这个权限中心应当是多租户的，传统的老架构不少是各自独立的，那这里咱们就考虑是否可合并。我这里没有列完，这部份内容实际上是很是多的，也是很是重要的，是真正提升开发效率和效能的地方，每每也是不少公司欠缺的部分，有些公司可能有部分能力，更多的时候仍是像咱们以前说的，只是纯技术组件，而不是服务，耦合度也较高，也没有真正的支持多用户能力，使用起来也很繁琐，这样的东西和传统的架构方式并无太大区别，也没有真正的为业务和开发去考虑，颇有可能仍是各自为政重复造轮子，最终形成流程的繁琐和数据的不一致。

技术组件、公共基础服务、技术服务这三块是真正须要公司下大力气去规划实现的内容，也是比较容易把控和落地的，这里面操做的空间很是之大，作好以后给业务带来的好处是直接可见的。

 DevOps&&AIOps

DevOps 层面，咱们这里讨论的可能不是技术层面的实现，如如何使用 jenkins，写好 pipeline 进行 CICD，也不是如何利用 docker + k8s+Jenkins 作到动态 CICD 等，也不是如何作好 DevOps 模板，而更多的是 DevOps 现状作一些思考。

首先在实施 DevOps 时候，咱们发现不少项目组只是在 DevOps 工具链方面作了很好的处理，好比采用 CI/CD 方法论，加上 git, Gradle, maven ,jenkins，jacoco, sonar, CodeDeploy, Ansible,docker 等等工具链，已经让 CICD 在企业和公司里实行了起来，而且还能运用好运维平台，在自动化方面作了不少工做，这些都给企业带来了好处和效率的提高。

其次，DevOps 是能够贯穿需求，设计，开发，测试，上线，运维等多个方面的，它应该是要以应用为中心，以组织做为依托，来促进公司整个效能的提高，进而还能推进创新能力的加强，和促进人才、组织的优化，这才是有价值的 DevOps。

不足的方面是文化、组织、流程方面，咱们发现技术方面不少问题实际上是管理的不足带来的，DevOps 为了打破开发和运维墙而产生的文化在传统企业的组织层面还比较难调整，泰勒的金字塔管理结构仍是持续发挥做用，部门墙仍是继续维持，做为技术实施方的咱们，确定是但愿完美的解决问题，在一开始就让团队或者组织进行调整，其实这对于不少企业来讲是不太现实的，但咱们发现随着 CI、CD、CO 能力落地，组织间的配合愈来愈多，人员的技能在逐步渗透，这时在没法立马解决组织层面问题的时候，能够逐步的让团队发生技术融合，职责传递和培训，从而推进团队的整合，造成咱们指望的，融合的 2 个披萨团队，完成真正的 DevOps 文化和工具的全面落地。

AIOps 层面：

在咱们 Ops 运维方面，咱们已经从过去的人工运维走到了现在的自动化运维，但咱们发现这里的自动化只能是管控台，工具和脚本层面，若是在人的思想方面作到自动化实际上是比较困难的，那也必将形成咱们人工的进行分析和决策，也须要人工的进行检测点及规则点的录入，因此这也是 AIOps 能帮咱们带来的好处，AIOps 主要仍是在 AI 层面发挥它独有的优点，在数字化运营，智慧运维这块发力，这部份内容也是建设中台能够考虑的部分。

效能：

咱们的目标是持续的交付有价值且稳定的软件，效能方面实际上是贯穿整个项目的，我认为它不仅仅指研发效能这一个点的，咱们应该是思考如何站在总体的角度上去衡量团队和项目效率的提高，犹如坐在飞机上俯瞰大地，这里一个好的作法是成立一个平台型效能微团队，能按期的对项目和团队进行梳理，能够是任意方面，并能够借助一些产品和方法进行辅助，如利用看板，限制在制品数量等。另外这个团队重要的工做是能抽时间和站在更高的角度去发现整个中台的价值，改进点和缺陷，如造成好的公共支撑服务和标准化的服务，对中台进行不断优化和迭代。

时间仓促，涉及的东西不少，咱们此次只谈论了技术中台的部份内容，固然整个的范围远远不止这几部分，抛砖引玉，但愿有机会跟你们一块儿交流心得。

做者介绍

朱德明，腾讯云技术架构师，十年软件开发经验，《从新定义 Spring Cloud 实战》做者之一，业界首个微服务标准核心编写者之一，长期从事微服务和云原生方面的工做，研发过多款微服务产品，主导和参与了多个大型企业微服务架构和云原生架构的设计，咨询等工做。在微服务，云原生，互联网解决方案等方面有着丰富的实战和落地经验。