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

今天下午在腾讯云+社区社区分享了《基于Kubernetes 构建.NET Core技术中台》,下面是演讲内容的文字实录。

我们为什么需要中台

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

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

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

基于Kubernetes 构建.NET Core技术中台_第1张图片

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

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

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

基于Kubernetes 构建.NET Core技术中台_第2张图片

业务中台

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

应用中台

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

技术中台

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

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

为啥过去叫技术平台,现在就叫技术中台了呢?

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

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

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

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

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

在技术中台这里,最核心的就是集成中台:

1、集成各类企业内部ERP

2、集成各类公有云SaaS

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

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

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

数据中台

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

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

基于Kubernetes 构建.NET Core技术中台_第3张图片

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

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

基于Kubernetes 构建.NET Core技术中台_第4张图片

到 2020年, 超过50% 的企业将在生产中运行关键任务、容器化的云原生应用程序,k8s 成为容器编排工具的王者。

基于Kubernetes 构建.NET Core技术中台_第5张图片

基于Kubernetes 构建.NET Core技术中台_第6张图片

基于Kubernetes 构建.NET Core技术中台_第7张图片

基于Kubernetes 构建.NET Core技术中台_第8张图片

基于Kubernetes 构建.NET Core技术中台_第9张图片

现在, 所有云提供商提供托管 Kubernetes 服务,  甚至Docker和 DC/OS 集成 Kubernetes

为什么Kubernetes 能够如此成功?

  • 社区: 项目被捐赠给一个 OSS 基金会 (云计算原生计算基金会) 很早就和其他主要的成员 (尤其是红帽) 参与, 把它从谷歌分离, 并避免锁定在谷歌
  • 容器-本机: 一些协调器 (即 DC/OS) 将容器添加到现有的调度技术中, 这确实很灵活的, 但可以感觉到 "附加", 就包括微软的service fabric 也是把容器的调度技术添加进去,kubernetes 确实天生设计为容器调度
  • 以规模应用的最佳实践为基础: Kubernetes项目组的成员用Go语言重构了Brog系统,并得到了Brog系统开发者的大力支持。其他项目 没有这样的成熟度。

Kubernetes 的网络效应现在如此强大, 以至于竞争对手们正在努力保持相关, 即使他们在某些方面客观地 ' 更好 '。

基于Kubernetes 构建.NET Core技术中台_第10张图片

基于Kubernetes 构建.NET Core技术中台_第11张图片

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

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

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

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

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

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

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

基于Kubernetes 构建.NET Core技术中台_第12张图片

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

基于Kubernetes 构建.NET Core技术中台_第13张图片

为什么选择.NET Core

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

基于Kubernetes 构建.NET Core技术中台_第14张图片

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

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

  • 语言: 用了哪些开发语言,如:C++/C#/Java/Go/PHP/Python等等;

  • 组件:用了哪些组件,如:消息队列组件,数据库组件等等;

  • 流程:怎样的流程和规范,如:开发流程,项目流程,发布流程,监控告警流程,代码规范等等;

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

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

选择合适的语言

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

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

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

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

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

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

  • 选择靠谱的云服务商;

  • 选择云服务商的组件;

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

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

  • 开源社区活跃度;

选择了云服务商以后,就会有很多的产品你可以选择了,比较存储,队列这些都会有现成的产品,这个时候就纠结了,是用呢?还是自己在云主机上搭呢?在这里我的建议是前期先用云服务商的,大了后再自己搞,这样会少掉很多运维的事情,但是这里要多了解一下云服务商的组件特性以及一些坑,比如他们内网会经常断开,他们升级也会闪断,所以在业务侧要做好容错和规避。
关于开源组件,尽可能选择成熟的,成熟的组件经历了时间的考验,基本不会出大的问题,并且有成套的配套工具,出了问题在网上也可以很快的找到答案,你所遇到的坑基本上都有人踩过了。

基于Kubernetes 构建.NET Core技术中台_第15张图片

. Net 基金会是我们围绕. net 生态系统进行开放式开发和协作的重心。. Net 基金会在其管理下拥有50多个项目和数百个回购项目。开源软件基金会提供保护、支持、服务和最佳实践, 帮助每个项目取得成功, 并发展人和软件的生态系统。微软开源.NET 和Kubernetes项目的运作方式类似,也是成立了.NET基金会,避免.NET锁定微软。

基于Kubernetes 构建.NET Core技术中台_第16张图片

Linux 基金会执行董事 jim Zemlin 说, "有10个开源项目, 投资于具有可持续生态系统的项目"。. Net 是其中之一。CNCF 跟踪前30名最高成长速度的开源项目。在 X 轴上是提交的 oss 项目速度和 y 轴上的 PR 和问题,  # 由圆的大小表示。右上角越远, 项目的活动就越多。Linux 内核 #1, 其次是Chromium、Kubernetes 和微软文档。 . net 是 #1 应用程序框架。

 

基于Kubernetes 构建.NET Core技术中台_第17张图片

2001年12月-2002年2月。

一个新的平台诞生了。与惠普、英特尔和其他公司一起, 创建了 ECMA-335 标准, 该标准定义了支持多种编程语言的公共语言基础结构,C# 和 Visual Basic. Net。 F # 于2007年晚些时候发布, 但今天还有20多种. net 语言。Visual Studio. net 已发布, 并将 c#、VB、C++ 开发都包含在一个框中。这是第一个真正跨多种语言集成的 IDE。

Mono项目开始。CLI 规范使其他人能够创建自己的. net 实现。尽管 Microsoft仅为适用于 windows 构建了第一个. net 框架, 但该规范有意地可跨操作系统和芯片组移植。Mono 项目开始由 Miguel de Icaza 牵头, 目标是在 Linux 和类似 unix 的平台上实现 Microsoft 新的. net 开发平台。后来,由 Miguel de Icaza创办了 Xamarin, 专注于跨平台、本地、移动开发, 并在 Mono 的基础上构建。这允许开发人员使用 c# 和. net 为 iOS 和 Android 构建应用程序。Unity游戏开发也从Mono 中出现。

2008年

asp. net MVC web 开发堆栈作为开源发布到 CodePlex。这是微软第一个作为开源发布的应用程序开发框架。但是, 基础运行时和编译器仍处于封闭状态。

2014年。

天方夜谭的事情真的发生了。2014年初在微软的 BUILD 会议上, C# 之父 Anders Heillsberg 在舞台上宣布了. net 编译器平台 “Roslyn” 的开源。11月下旬,. net Core 项目开始启动,对外公开。技术世界感到震惊, . net 社区感到兴奋。. Net Core 是一个新的云原生实现. net, 适用于跨平台、超大规模服务以及小型物联网设备。它的目的是将. net 引入未来15年的计算。而社区也一直给予极大的支持.....。

2016年。

Mono 回家了。2016年初, 微软终于收购了 Xamarin, 并将 Miguel de Icaza 引入开发者部门。Mono 加入. net 基金会, 并得到 Microsoft 的正式支持和贡献。微软社区正式与 Mono 社区汇合。

2017年。

. Net Core 2.0 发布。我们的跨平台和开源实现. net 终于通过跨多个操作系统和编辑器的统一工具支持向世界发布。

2018年。

Winform 和 WPF 宣布开源。在 Microsoft Connect 2018 中, 微软宣布了 Windows forms和 WPF 桌面框架的开源。此后, 我们看到了不可思议的贡献和活动。社区现在有能力指导这些框架的方向。

2019年

. Net Core 3.0 发布。. Net Core 3.0 将 Windows 桌面工作负载带到. net Core 运行时, 这将允许自包含 exe、并行安装和更快的性能。Build 2019宣布 .NET Core 3.0 之后的下一个版本将是 .NET 5 。这将是 .NET 系列的下一个重要版本。将来只会有一个 .NET ,您将能够使用它来开发 Windows,Linux,macOS,iOS,Android,tvOS,watchOS 和 WebAssembly 等等。我们将在 .NET 5 中引入新的 .NET API、运行时功能和语言功能。从 .NET Core 项目开始,我们已经向平台添加了大约五万个 .NET Framework API。 .NET Core 3.0 弥补了 .NET Framework 4.8 的大部分剩余功能差距,支持 Windows Forms,WPF 和Entity Framework 6。 .NET 5 构建于此工作之上,利用 .NET Core 和 Mono 的最佳功能创建一个平台,您可以用于所有现代 .NET 代码。

2020年

将在2020 年 11 月发布 .NET 5,并在 2020 年上半年推出第一个预览版。将在 Visual Studio 2019、Visual Studio for Mac 和 Visual Studio Code 的未来更新中支持它。

基于Kubernetes 构建.NET Core技术中台_第18张图片

微软对该平台进行了大量投资, 特别是在性能方面。 流行的 TechEmpower 基准将 web 应用程序框架与 JSON 序列化、数据库访问和服务器端模板呈现等任务进行比较-. net 的性能比任何其他流行框架都要快。

基于Kubernetes 构建.NET Core技术中台_第19张图片

您可以使用. net 构建任何内容。 多年来, 微软在. net 方面进行了大量投资, 并统一了生态系统, 以支持构建任何东西。从桌面到游戏再到云,. net 是一个通用的编程平台, 支持各种方案。一旦你学会了一个, 你就可以很容易地拿起另一个。此外, 您还可以使用自己喜爱的工具和编辑器构建. net 应用程序, 或使用 mac 的 Visual Studio、Visual Studio code 或 Visual Studio。

转载于:https://www.cnblogs.com/shanyou/p/10841622.html

你可能感兴趣的:(c#,运维,测试)