微服务和中台是这几年非常时髦随处可见的词，最先在一批互联网企业中开始谈论和建设，并逐渐的蔓延至一些传统企业和传统的 IT 部门，以至于现在在构建信息系统时，很多企业都在说要建一个中台，但究竟要建成什么样还不是很清楚或者说有些迷茫，笔者在微服务出来的时候也不是特别的明白到底如何建好一个企业中台，只是跟着感觉走，随着主导和经历多个项目后，有了自己的部分认识，可以与大家在此分享。
我们认为中台的意义应该是什么，无论是技术中台，业务中台还是数据中台，我想它应该是为业务和组织而生，为能更加快速敏捷的响应业务的变化，给公司带来效能上的提升，价值上的提升，创新能力的增强，进而还能促进人才和组织的优化，这是中台所存在的意义。
首先在不知道微服务中台是什么样的时候，它一定不是这几个样子：
1. 堆砌技术组件就是中台
只堆技术组件，微服务中台或者说企业中台只包含常用的技术组件，比如使用 spring cloud 微服务框架，再加上 MQ,Redis, quartz,nginx,activity,servicemesh,docker 几个组件之后认为这个就是企业的中台，要什么技术能力拿过去用即可，说法其实并没有错，只是站的角度不同，确实是能力的抽象，封装和开放，但并不是纯粹的堆砌技术组件。
2. 拥有服务治理就是中台
为 spring cloud 这样微服务开发框架增强了服务治理的能力，然后在绑定上业务就是技术中台或者中台。
这样的看法不是完全正确，这只能代表在技术的基础底座和支撑上前进了一步，还远远不够。
3. 增加部分业务功能就是中台
对老系统增加新功能确实是构建中台道路上必须经历的一件事，但如果只是单纯的从增加新功能角度出发而不是为了能力组件化，服务化，封装和开放，协同作战的思想去建设，那么只是给老系统增加负担而不是减负。
4. Cloud Native 就是中台
Cloud Native 是目前比较火的领域，很多企业认为做了微服务，容器，DevOps 就已经构成了中台体系，这也是比较片面的看法，只能说有了这三大块，对于构建中台体系有了一个很好的基座，但真正的中台还并未出现。
刚刚上面我们认为中台应该不是什么样子，那到底中台应该是什么样子，有什么价值，就如我们上面所说，它一定是为业务和组织而生，你可以从很多角度去解读它，本篇文章我们结合在新项目建设中，我们先从技术中台方面来探讨一下技术中台的落地建设，后续我们再来讨论业务中台。
技术中台
如下图，我先把技术中台分为这几部分，当然它包含很大的范围和其他的角度，但我们可以根据这几点展示出部分技术中台思想：
容器平台，虚拟机
微服务框架 (分布式服务框架) && 微服务管理控制台
技术组件
公共基础服务和技术服务
DevOps&&AIOps
效能
容器云，虚拟机
虚拟机和应用上云对 Iaas 厂商有了更高的要求，不仅在稳定性和可用性方面要有出色的表现，更加应该在易用性和便捷性方面展示出强大的功能，这方面必须能提供具有丰富功能和配置的 UI 界面，它有助于我们在 Iaas 的配置和运维层面减少工作量，优化人员配置，提高我们对 Iaas 的掌控能力，这是一个有和优的问题，另外对于厂商的选择和团队的选择，一定是要能及时响应的。
虚拟机和应用上云对 Iaas 厂商有了更高的要求，不仅在稳定性和可用性方面要有出色的表现，更加应该在易用性和便捷性方面展示出强大的功能，这方面必须能提供具有丰富功能和配置的 UI 界面，它有助于我们在 Iaas 的配置和运维层面减少工作量，优化人员配置，提高我们对 Iaas 的掌控能力，这是一个有和优的问题，另外对于厂商的选择和团队的选择，一定是要能及时响应的。
对于采用了容器的厂商，起码要在这几方面需要做好，集群的管理和调度，网络方案，服务编排，日志方案，存储方案，应用和服务的管理，容器的监控和告警，镜像仓库的管理，镜像的打包和构建，用户的权限，优秀的 UI 操作界面等等。
同样的对于容器，如果它是一个优秀的产品，那它还应该是这样的：
充分开放的和可扩展的接口。
可以和多个产品进行对应快速，如微服务产品。
丰富和体验方便的 UI， 高度集成功能的 UI，可见即可得。
充分的对接 DevOps 文化，丰富的 CICD 流程，镜像一键打包。
容器应用与非容器应用通信，跨集群通信。
优秀的监控体系。
等等。
这部分的能力是让整个技术中台有一个好的基础设施层支撑，能快速的进行应用的部署和交付，出问题时能迅速定位和恢复，降低 MTTR, 并能充分的利用现有资源进行合理的分配，让技术和业务降低耦合，划分出业务实现者与技术支撑的 BC，关注各自的领域，所以你需要一个非常靠谱和好用的底层支撑。
微服务框架 (分布式服务框架) && 微服务管理控制台
对于传统老应用而言，它可能是传统的单体应用，整个系统的功能都融合在一起。它们在迎接需求剧烈变化和传统开发迭代方面遇到了瓶颈，那么在转型时就会考虑服务化的架构，在做服务化架构时，我们就需要一个完整而健全的分布式服务化框架来帮助我们，诸如 Pivotal 的 Spring Cloud 框架。
但这里要提醒的是，如果你要打造一款真正的技术中台，我认为一个纯粹的 Spring Cloud 的框架是非常不够的，它只能说是一款开发框架，而不是一个真正的微服务产品，不能为业务开发提供充足的保障。那么究竟什么是一款完整的微服务产品呢? 我起码认为它应该拥有这两个基本的能力：
第一，要拥有微服务框架技术能力。
第二，要拥有完整的服务治理能力，拥有应用全生命周期的管理能力。
第一部分是基础的微服务框架能力，这里面应当包括：服务注册，服务发现，负载均衡，熔断保护，服务路由，服务通信等。
第二部分是拥有完整的服务治理能力，这里面的内容比较多，一般会有： 服务的管理，可视化治理界面，服务构建发布，分布式事务，流量控制，监控告警，服务契约，链路跟踪，灰度发布，服务降级等等。
微服务产品这一节可以单独拿出来说，这里就不过多讨论，其实好的产品应该还要有其他部分考量，如对接各种其他技术组件和其他产品的能力。
业界的微服务产品有很多，这里列几款：
腾讯 TSF 产品，Tars 产品。
阿里的 Dubbo, EDAS 系列。
华为的 ServiceComb，ServiceStage 系列。
蚂蚁金服 SOFA 系列。
Pivotal 的 Cloud Foundary。
微软的 Service Fabric。
网易的轻舟微服务。
这部分的内容是我们技术中台的基座，它可以帮我们解决大部分在开发测试，网络通信，分布式等方面的难题，也是我们在构建微服务应用，技术组件，公共支撑等方面的基础，加上完整的微服务治理能力，能充分帮我们解决在微服务拆分后的管理和运维问题，所以这部分内容是相当重要的。
技术组件
我们这里探讨的是中台能力不是只堆砌技术组件，不是缺消息队列和定时任务调度框架就装一个 RabbitMQ 和 Quartz，然后就抛给业务开发去使用，我们而是思考如何让业务开发更好更快速地上手使用，如何让多个项目组使用时保证组件的稳定和可用性。比如项目需要使用某个技术组件，我们可以经历以下几个步骤：
写一个文档，告诉开发需要哪些依赖，引用什么样的配置即可。
发现每个人都要这样很麻烦，我们即把依赖引入父工程或公共依赖。
发现每个人还需要配各种配置后，我们可剩下不能减少的配置，如服务名，其他的都放在远程配置中心或环境变量或其他地方。
增加 UI 可视化能力，可视化管理能力。
标准化，微服务化，业务域、系统级、公司级别统一微服务，多租户能力，如给每个应用分配权限，单独的进行数据操作，维护，管理。
发现需求，优化迭代。
通常一般的只是做 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 层面发挥它独有的优势，在数字化运营，智慧运维这块发力，这部分内容也是建设中台可以考虑的部分。
效能：
我们的目标是持续的交付有价值且稳定的软件，效能方面其实是贯穿整个项目的，我认为它不单单指研发效能这一个点的，我们应该是思考如何站在整体的角度上去衡量团队和项目效率的提升，犹如坐在飞机上俯瞰大地，这里一个好的做法是成立一个平台型效能微团队，能定期的对项目和团队进行梳理，可以是任意方面，并可以借助一些产品和方法进行辅助，如利用看板，限制在制品数量等。另外这个团队重要的工作是能抽时间和站在更高的角度去发现整个中台的价值，改进点和缺陷，如形成好的公共支撑服务和标准化的服务，对中台进行不断优化和迭代。
