如今Cloud Native，也就是云原生，这个技术名词提的真是不少，但对于企业与开发者来说，具体的平台架构部署以及未来发展等诸多问题却还在探讨的过程中。
正所谓Cloud Native时代下，容器、微服务以及DevOps怎样用才能又快又好？中小企业体量不大，个人开发者势单力薄，Cloud Native应用实践还将如何开展？当然还有大家伙儿普遍关心的一点，如今火爆的Cloud Native究竟未来路在何方？
——总之，关于Cloud Native，开发者们迫切想要“一探究竟”心情才是关键所在。
对此，日前京东云特别在京举办了主题为“Cloud Native时代的应用之路与开源创新”的沙龙活动，重点聚焦云原生时代下，容器、微服务、Serverless以及数据库等技术应用与开源创新，同时高度结合京东云在Cloud Native以及开源领域的核心技术与一系列成功实践为开发者们现场答疑解惑！
沙龙现场座无虚席
会上，京东云专家架构师刘俊辉为与会开发者带来了有关“Kubernetes的兴起”的主题分享。作为首位进行技术分享的嘉宾，刘俊辉将介绍的详细内容做了大致总结，主要涉及虚拟化的起源以及其应用的驱动力量，内容涵盖从虚拟机到容器的技术进化过程；其中比较重要的一部分则是关注Kubernetes的兴起以及针对云原生平台未来发展的预测性解析。
谈及虚拟化，他表示在很早时期，为了解决物理服务器的种种弊端，虚拟化就已经被发明，只是并没有得到很广泛的应用，伴随互联网应用的大规模出现，这种状态才被改变。在虚拟化为王的时代，代表的应用架构还只是单一应用的一体化架构，最主要的技术是Hypervisor，那时的顶级玩家title被一家名为VMware的企业轻松取得，从物理机到虚拟机的架构迁移则完成了第一次虚拟化运动的主要内容。
京东云专家架构师 刘俊辉
“有一就会有二，对于技术圈子来说，第二次虚拟化运动的主要驱动力聚焦于提高资源利用率、应用的启动速度以及减少操作系统的开销等，这才促成了基础设施从虚拟机向容器方向的平滑转移，其中最重要的就是微服务架构，这局技术升级的赢家则为Docker。”刘俊辉进一步表示。
如果简要总结下容器的特征，其实可以概括为是适应微服务发展的一个恰当的虚拟化平台。其具备的独立封装性，意味着自身就包含了完整的依赖关系，就算变换位置也不会带来功能性的影响，部署的随心所欲是吸引大众的首要因素。
换句话说，当我们在纠结虚拟机的内存、CPU的数量、资源如果闲置将如何高效分配给他人使用的诸多问题时，容器已经替代性地实现了更小的资源分配，将计算部署到有能力被运行的地方；更重要的一点，较小的开销让企业不再踌躇是否需要“背负”一个操作系统的价格；一定程度的隔离，对于单租户或者应用下层的安全保障来说，绝对在接受范围之内。此外，在微服务的架构下，应用的快速以及灵活性也让容器优于虚拟机，有机会广泛发挥作用。
容器以动态、可靠以及弹性著称，我们通常所说的Kubernetes，又是如何通过分离平台和应用来显示以上这些优势的？关于此类问题，刘俊辉总结道：”完成这样的部署，主要归功于提供了开放的标准接口与基础设施对接。据了解，目前比较流行的开放接口CRI，也就是Container Runtime Interface。尽管目前比较标准的Kubernetes都使用Docker Runtime，但可以把它换成任何的Runtime，完全没问题；此外如今在Kubernetes的生态圈中网络插件的资源十分丰富，选择较多。“
关于这一点，据了解，Kubernetes缺省的应该是flannel，但是各大云厂商包括京东云在内，都为Kubernetes提供了自己的网络插件，其中存储的插件是Kubernetes比较新的一个插件接口，可以提供给容器一个持久化存储卷，而至于这个持久化的存储卷究竟是分布式存储还是文件系统，抑或是定项存储提供，完全由插件来决定，而接口只负责存储卷的特性。
从分享中我们得知，目前来看云原生平台发展的趋势可以被概括为几个方面，分别是全托管的Kubernetes服务以及更多的Kubernetes开放的接口；还有面向特定领域的云原生平台等。
”关于Kubernetes服务，其实京东云所做的实践被叫做JCS Kubernetes，并且已经通过CNCF的一致性认证，这表示在其他已经通过一致性认证的Kubernetes平台所部属的业务，可以百分百部署在京东云Kubernetes集群服务商，无须关心平台运维，只要细心把控应用即可。“他补充道。
除了上述提及的插件系列之外，关于计算、网络以及存储的基础设施服务部分，还有一些其他的通用应用服务在列，例如数据库服务；基于身份、基于租户认证以及访问权限的管理；涉及监控、告警以及跨云部署等方面，其中高效完成业务在不同平台之间的迁移工作也十分关键。
在过去的十年间，微服务的理念以及架构被大量采用，王碧波作为长期从事服务基础架构相关研发工作的技术专家，目前主要负责京东云分布式服务框架、API网关等产品以及京东内部服务治理框架等技术内容，对此一点儿也不陌生。
看似熟悉的微服务架构应该具备哪些能力？常见的微服务架构各有什么特点？服务网格的概念和发展状况如何？他来解答最合适。这不，王碧波作为本次沙龙的第二位分享嘉宾就进行了一场主题为“云原生与微服务架构”的技术演讲。
分享初始，王碧波就抛出了问题一枚：一个好的微服务架构应该具备哪些功能？”其实总结来看主要包括四个方面能力，关乎整个生命周期的过程管理；微服务场景下功能实现的辅助；功能之间相互调用的能力以及在整个微服务系统中做运行观测的能力等。”
比方说为了系统的考虑，大家都希望有些设计可以服务本地，在本地部署缓存；但是当数据发生变更的时候，本地缓存的机制更新如何被设计就是个问题，也是经常容易出现bug的地方，这种事情就是微服务框架应该着重思考的。
京东云专家架构师 王碧波
谈及最近红火的服务网格，王碧波表示服务网格最大的特点就是，所有的策略调整都以一个动态的配置变更方式来实现，而不是采用变动代码的方式，进而实现一种业务逻辑与服务治理彻底被切分的状态。
举例来说，Kong Mesh就是服务网格的具体实现。在控制面中，涉及到一个管理集群，有关微服务的相关治理策略都会通过配置的方式写入数据库中，而每个服务旁都会部署一个Kong的代理服务，会到数据库中读取配置好的服务治理逻辑然后加以处理。
据了解，之前的Kong相当于本身就是一个有关API网关的开源项目，后来被应用到服务网格中，所以据实测其网格调用的服务能力非常强悍；另外Kong的系统组建十分简单，表现为依附，架构简单且实践起来较为便捷，本身又是基于openresty。
但王碧波强调，这并不代表高可用的Kong没有缺陷。一方面，控制面的能力并不丰富；另一方面，生态圈本身不强大，主要还是以Kubernetes插件的方式扩展，开源生态十分欠缺。
谈及微服务架构的典型项目，所知数量不少，例如Prometheus这个完整的监控方案。对此他总结道，这款监控方案将数据查询、预警报警等全部整合在其中，与其他监控方案存在差别的地方主要集中在部署、SDK等方面。
首先从部署层面来说，监控方案本身就是一个TSDD，自带数据库降低了部署难度；此外提供的SDK，很容易产生符合规范的商标数据；更重要的一点，其他监控方案主要采用主动上报的方式，而Prometheus以拉取形式为主，即一旦产生符合规范的数据，只要具备一个可供拉取的地址就可以完成服务端拉取的策略，比较实时性。
作为技术人，究竟应该如何拥抱微服务呢？针对此问题，王碧波对现场的开发者们说，拥抱微服务，最关键的一点还是应该积极适应Kubernetes。目前这是过去十年间在软件领域比较革命性的”发明创造“，尽管线上服务确实会因为Kubernetes产生很多风险，但不断向其靠拢的心还是要有的。
目前关于服务治理这个层面，所存在的最大问题其实是一种纠结：现在究竟要不要”上马“服务网格呢？需要明确的一点，服务网格确实可以将业务逻辑和服务治理完全独立，并促使服务治理、变成动态分配的情况，这一点 的实现同语言以及架构均无关系；但架构复杂性以及性能损耗等是不容忽视的问题。
据了解，京东云在微服务架构方面有一些产品十分值得提及，例如关于全生命周期管理的Kubernetes的集群；具备超级弹性伸缩、高可用还满足云部署等需求的DevOps；在功能实现方面主要包括函数服务、消息队列、对象存储等产品组件；如果着眼运行观测，日志服务、监控、调用链关系以及调用服务等更是必不可少。
分享过后，现场开发者还针对企业层面对微服务的观念以及何时“上马”微服务架构等诸多问题展开了深入探讨。
现如今究竟什么是Serverless?
应该如何打造自己的Serverless服务，有哪些标准或者范式可以参考？
Serverless的现在和未来走向哪里？
云原生给Serverless带来了什么？
开发者们谈及针对Serverless的疑问或许比想法还要多，来自京东云的技术专家张金柱却又自己的一番见解。
“这是云时代的一种架构思想。如今给大家提供了非常丰富的开发框架以及技术组件，时代很赞；此外云计算将大量的社会资源，例如计算以及存储资源集中到一起形成规模效应，这两点确实成就了Serverless。”
从IaaS过渡到微服务以及现在的Serverless，云计算让业务人员不用过多担心技术，而是专注业务；如果从软件架构发展的角度，单体结构发展到微服务以及分布式，这都是必然的技术迭代。“我们可以简单认；Serverless是云SaaS，是一种抽象。得益于底层的标准化，让Serverless成为一种可能。”他进一步补充道。
京东云架构师 张金柱
在有关Serverless的分享中，张金柱还对其架构特点进行了总结可以概括为运维无负担、极强的弹性伸缩能力以及按需付费的原则。
例如AI场景中针对视频和图片的分析和处理，这可能会涉及图片鉴黄以及压缩手段。一张图片，需要根据设备不同来调整大小甚至形状，这样的需求在过去的基础架构上很难完成，过程复杂。但在Serverless中，只需要将图片上传至对象存储，然后去触发预先定义好的Function，按照需求剪裁成不同设备所需要的尺寸并回传存储。
精彩的现场互动
不可避免，Cloud Native确实对Serverless产生了影响，对于Serverless这个只属于云时代的架构思想，规模化以及更加标准的方式、所提供的无上限的资源为其弹性的伸缩提供了基础。此外，云计算将一些基础细节加以隐藏，这不单单是应用架构方面，当然还涉及到PaaS服务。
云计算基本上会以更加专业的方式去提供组件，包含一种趋势；伴随云计算产生，会有一些人去解决基础的技术问题，还有一些人去解决业务问题，分工不同。关于Serverless的挑战和未来，引用伯克利给出的两个重要总结，其实现在的Serverless有两大退步：忽略了数据，或者说数据处理的要求；天然的无状态对于分布式并不友好，例如一致性问题以及事务性问题等。
精彩分享仍在继续，现场气氛始终火热不减。
开发者们热情不减
当前，云原生时代下开源数据库究竟有何突破发展？针对此问题，重度的开源爱好者刘奇也来到现场，针对数据库发展趋势，探讨了云计算为开源数据库带来的机遇与挑战，并结合数据库在功能创新以及用户体验升级方面深入探究了云原生、云计算以及开源之间密切的技术关联。
PingCAP 联合创始人兼 CEO 刘奇
在“云原生时代数据库的发展趋势 ”的分享中，刘奇表示，TiDB目前做的一些关于Computing的实践，很有意思的点就是每一层都可以做成Computing。如果综合去看其中的差异，其实TIDB是被当成计算上的Computing来实现支持，相当于被做成插件，如此形式在计算层可以，在存储层也可以，而存储层实现多个插件，这样一来整体结构的灵活性就会体现的非常好。
针对图数据库是不是将来发展的趋势，以及关系数据库选择的问题，刘奇认为最主要的还是依靠场景的差异性来判断使用。有些场景需要图数据库，而有些场景则需要关系数据库，例如风控领域图数据库就会应用的比较多。图数据库中快速索引关系会非常快，相对而言关系数据库则是更加方便选择，主要还是依照业务需求。
尽管京东云针对云原生的精彩分享已暂时告一段落，但关于微服务、容器、无服务器以及开源数据库等技术探讨依旧在火热进行中，敬请关注京东云技术沙龙的后续活动。
System.out.println("点个在看吧！");
console.log("点个在看吧！");
print("点个在看吧！");
printf("点个在看吧！\n");
cout << "点个在看吧！" << endl;
Console.WriteLine("点个在看吧！");
Response.Write("点个在看吧！");
alert("点个在看吧！")
echo "点个在看吧！"
阅读原文可获取沙龙PPT！