基于Kebernetes 构建.NET Core技术中台

我们为什么需要中台

我们现在处于企业信息化的新时代。为什么这样说呢？

过去企业信息化的主流重心是企业内部信息化。但现在以及未来的企业信息化的主流重心是企业外部信息化。

中国互联网从1998年算起（新浪搜狐网易都在那一年成立），到现在过去了20年。在这20年里，也就两个阶段。按to C的分法就是PC互联网时代、移动互联网时代，按to B的分法营销时代、交易时代。第一个10年（1998-2008），不管你是搞音乐图片视频，还是你搞新闻、爬虫新闻、博客论坛，本质上就一个事：做内容拉消费者流量然后拉企业广告变现。到了第二个10年（2008-2018），给企业倒流量，企业已经不信了，你给我多少点击量没用，我归根到底还是得看我卖出了多少东西。所以中国互联网进入了交易时代。从2008年之后，中国电子商务公司如雨后春笋爆发，就是因为这个历史大规律背景。从现在开始到未来十年（2018-2028），进入了第三个时代。因为在第二个十年，有了消费者也有了订单了，但是上游生产、采购、研发设计不给力啊。市场机会转瞬即逝，谁快谁就能抓住机会。所以上游生产、采购、研发设计必须要变革，来适应下游消费者订单。这就是中国互联网企业纷纷进入to B市场纷纷进入企业服务领域的根本历史大背景。

中国企业软件，从内部单部门单岗位应用，进化到内部多部门多岗位应用，后来又到整个企业乃至整个企业集团的全部应用。再往大长，就必须要突破企业边界，进化到企业的衣食父母（客户）的信息化，这就是我说的连接客户（消费者），让消费者直接参与到企业IT业务流程处理中。进而再进化到连接企业的上下游，为消费者需求与订单进行通力合作、敏捷互动。最后再进化到连接社会基础设施，如工商税务海关银行、交管车管、国土住建、社保民政、质检安监…。

现在以及未来的企业信息化的主流重心是企业外部信息化：连接消费者、连接产供销研上下游、连接社会基础设施单位。因为要连接消费者。也就是说，消费者在哪里，我们就要连接哪里。这势必造成了IT应用微型化、场景化、碎片化。尤其现在是移动互联网时代，App技术特性决定了流量是被碎片化的不能聚合的。

中国的消费者是巨量的。中国每一个省就相当于欧洲的一个国家的大小、GDP规模、人口数量。我们必须把我们过去铁板一块的应用拆分拆分。与外部连接相关的的应用场景，一定要做成微型化、场景化、碎片化、微服务Open API技术，这样便于快速连接、快速迭代改变。

业务中台

业务中台，主要就是业务支持，比如统一会员、统一认证、统一营销、统一订单、统一库存、统一支付，这些统一的东西来自一个地方，分别支持多个系统对业务的管理要求，不同系统开发的时候，可以直接从这里获取这个功能，而不需要再开发，从而把更多的系统连接在一起。 业务中台使得任何一条业务线都具备整个公司的核心能力。

应用中台

做商业应用级别的基础设施，就必须拥有应用中台，如企业云盘、音视频会议、企业直播、IM、多触点交互机器人、聚合支付、电子发票、电子合同、电子凭证、银企直联…，他们都带有业务应用特征，不是纯技术。但是他们又不是具体的业务场景应用，不是类似零售、制造、人力、财税、OA、供应链、CRM等等。

技术中台

腾讯组织架构调整中，我印象比较深刻的是“腾讯成立技术委员会，通过内部分布式开源协同，加强基础研发，打造具有腾讯特色的技术中台等一系列措施，促成更多协作与创新”。

技术中台，过去我们把他们叫做技术平台。它是企业应用的技术平台。

为啥过去叫技术平台，现在就叫技术中台了呢？

因为过去技术平台是恒定的。也就是说，你发布了一个版本，你用一年它也是这个功能能力，你用十年它也是这个功能能力，功能能力是不变的。 但是，有了数据和AI驱动，这个技术平台就不恒定了。它里面的很多功能特性就在天天进化、天天模型、参数在自动调节。所以我们就把技术平台升级到了技术中台的概念层面。

不要把中台部署到企业内部私有环境中，这是错误的方向，这是老旧的技术平台的思维。如果部署在企业内部私有环境中，它就接受不到社会360度海量数据的训练了，它只能接受你这一家企业单点的数据训练了，所以它就成三岁小孩了，智力不增长了。

如果你部署在公有云或者专属云上，就会接受我们日常360度的数据训练，它的智力就会天天进化，随着社会动态变化不断自动调节适应了。

你可以把和外部连接的应用放到公有云上，因为他们是外部连接型的，你把他们放到你的内部私有环境中他们就跑不起来了。

你当然可以把你只内部的应用放到你的内部私有环境中。要把公有外部连接的应用和纯内部使用的应用连接在一起，这就需要到了技术中台。按照这个角度来看，中台也不应该部署在私有环境中啊。它一定要放在混合云环境中，这样才方便公有云应用和私有云应用连接打通。

在技术中台这里，最核心的就是集成中台：

1、集成各类企业内部ERP

2、集成各类公有云SaaS

3、集成各类互联网电子商务Open API

4、对外统一开放API，便于外部生态应用接入与融合

你看，大量都是内外连接能力，需要经常变动、需要内外通畅。

数据中台

所谓的数据中台，是带有产业主数据、画像标签、业务模型、业务算法的。

数据中台，利用获取的各类信息、行为习惯信息和算法，获取分析结果，比如业务中台参照的客户标准和分类方法就是基于数据中台运算的分析结果，例如需求偏好（客户标签）。 数据中台的数据来自业务系统，有原始数据（不同频次的历史快照+实时数据）、共享数据（拉到一起）、萃取数据（已经整理的标准化数据、标签、模型），再反哺给业务中台用起来。以精准营销为例，数据中台支持算法，业务中台基于算法的结果，支撑实时推荐。

基于K8s&.NET Core搭建技术中台

深圳市友浩达科技有限公司根据企业在架构、技术、研发、运营、业务发展等方面的实际需求，打造“容器”+“微服务”+“AI”的创新性解决方案。

友浩达微服务能力中台基于腾讯云容器服务TKE 领先的 Docker容器技术和.NET Core 微服务架构方案，以及 AI 引擎和大数据服务能力，为企业提供了大型应用微服务化运维和管理能力、容器集群管理、容器部署、服务运维、持续集成、持续部署、租户隔离、微服务治理、APM 性能管理、AI 模型服务等功能，赋能企业应用敏捷落地，助力企业数字化、智能化转型。

1、使用TKE 搭建的统一容器 PaaS 平台，将软件从底层硬件中解耦，提供更好的可移植性和速度，打造轻量、快速、高效、友好的服务运行及开发环境，极大的降低了运维成本；

2、开发微服务架构应用，实现多个微服务组件可以独立部署，通过统一通信协议互相连接，保证独立性和高可用性，同时简化了部署、监控、运维、治理与微服务应用生命周期的管理；

3、使用微软先进成熟的Azure DevOps 产品，重新规划设计开发测试运维的工作流程，优化开发测试标准的同时将日常繁琐的重复性工作交由平台来自动化完成，包括源代码管理、自动化构建、自动化测试、持续集成、持续部署等，显著的提高了应用系统的开发迭代效率；

4、基于 Kubernetes 核心支撑能力，实现对于应用服务的灰度发布、滚动升级、弹性伸缩、故障自愈、配置管理、服务高可用等多种治理手段，提供了统一的企业IT管理平台，提高了企业IT管理效率；

5、基于.NET Core的高效率开发微服务，高性能运行的微服务系统开发

技术中台架构以K8S+Docker容器化技术为基础构建运行支撑平台，基于容器化技术的灵活伸缩能力数据集成、服务集成、数据利用、公共服务、DevOps，形成企业级的技术中台。总体架构图如下：

服务网关是所有应用系统对外访问的流量入口，能够实现各个应用的访问，以及应用之间的相互访问能力，并且整体提升访问的安全性，总体访问过程如下图：

为什么选择.NET Core

说到技术栈，脑海中是不是浮现的是这样一幅图？

有点眼晕，以下只是我们会用到的一些语言的合集，而且只是语言层面的一部分，就整个技术栈来说，这只是一个开始，从语言开始，还有很多很多的内容。

整个技术栈我的理解包括 4 个层面的内容：

• 语言： 用了哪些开发语言，如：C++/C#/Java/Go/PHP/Python等等；

• 组件：用了哪些组件，如：消息队列组件，数据库组件等等；

• 流程：怎样的流程和规范，如：开发流程，项目流程，发布流程，监控告警流程，代码规范等等；

• 系统：系统化建设，上面的流程需要有系统来保证，如：规范发布流程的发布系统，代码管理系统等等；

在创业公司，没有大公司那些完善的基础设施，需要我们从开源社区，从云服务商甚至有些需要自己去组合，去拼装，去开发一个适合自己的组件或系统以达成我们的目标。

选择合适的语言

• 选择团队熟悉的/能掌控的，创业公司人少事多，无太多冗余让研发团队熟悉新的语言，能快速上手，能快速出活，出了问题能快速解决的问题的语言才是好的选择。

• 选择更现代一些的，这里的现代是指语言本身已经完成一些之前需要特殊处理的特性，比如内存管理，线程等等。

• 选择开源轮子多的或者社区活跃度高的，这个原则是为了保证在开发过程中减少投入，有稳定可靠的轮子可以使用，遇到问题可以在网上快速搜索到答案。

• 选择好招人的 一门合适的语言会让创业团队减少招聘的成本，快速招到合适的人。

• 选择能让人有兴趣的 与上面一点相关，让人感兴趣，在后面留人时有用。

选择合适的组件和云服务商

• 选择靠谱的云服务商；

• 选择云服务商的组件；

• 选择成熟的开源组件，而不是最新出的组件；

• 选择采用在一线互联网公司落地并且开源的，且在社区内形成良好口碑的产品；

• 开源社区活跃度；

选择了云服务商以后，就会有很多的产品你可以选择了，比较存储，队列这些都会有现成的产品，这个时候就纠结了，是用呢？还是自己在云主机上搭呢？在这里我的建议是前期先用云服务商的，大了后再自己搞，这样会少掉很多运维的事情，但是这里要多了解一下云服务商的组件特性以及一些坑，比如他们内网会经常断开，他们升级也会闪断，所以在业务侧要做好容错和规避。

关于开源组件，尽可能选择成熟的，成熟的组件经历了时间的考验，基本不会出大的问题，并且有成套的配套工具，出了问题在网上也可以很快的找到答案，你所遇到的坑基本上都有人踩过了。