让 Cloud Native 飞，Pick 干货，看这里、看这里！

TA，被称为技术群中的”当红炸子鸡“，丝毫不为过；

TA，帮助企业部署新业务特性，迅雷不及掩耳；

TA，应用中充斥”弹性、调度、伸缩性“等众优势，秒秒钟征服you；

TA，站在技术前沿，身边全是以一当十的”弄潮儿“，例如微服务、容器、Serverless……

pick一下，我们发现，如今符合上述特征的，很明显就是Cloud Native嘛！

这不，就在前不久刚刚结束的京东云技术沙龙活动中，多位技术大咖面对面针对Cloud Native进行了深入探讨，涉及容器、开源数据库等诸多技术层面，干货满满。

沙龙现场座无虚席

此外，现场超百位开发者热情参与了交流与互动，尤其对容器、微服务、Serverless等技术应用与开源创新十分关注。想必这些探讨也将为云计算、架构等相关领域的从业者们提供借鉴与新思路，十分值得广大开发者们认真学习与总结！

Kubernetes的兴起（京东云专家架构师  刘俊辉）

开场初始，京东云专家架构师刘俊辉在“Kubernetes的兴起”的主题分享中表示，其实众所周知的“虚拟化”在很早时间就已经被“发明”出来，主要是为了解决物理服务器的种种弊端；但碍于实际情况，并没有得到广泛应用，伴随着互联网应用的大规模出现，这种情况才得以根本改变。

我们了解到，在虚拟化“称王称霸”的时代，典型的应用架构还只是单一应用的一体化架构，涉及的技术主要是Hypervisor，从物理机到虚拟机的架构迁移完成了第一次虚拟化运动的主要内容，但是人们关注的是资源利用率的提高以及硬件升级维护的便利性等层面。

随着技术的更新迭代以及企业级需求的不断变化，第二次虚拟化运动闪亮登场！人们聚焦于提高资源利用率、应用的启动速度以及减少操作系统的开销等，果断促成了基础设施从虚拟机向容器方向的平滑转移，其中最重要的就是微服务架构，这局技术升级的赢家则为Docker。

刘俊辉简单举例说明了有关微服务架构的要点，比较大型的网站设置有web服务器，但是其中占用的内存资源甚至比操作系统占用的还要多；但如果将大型网站切割成小部分，尽管做到了每个部分只占用很小有限的内存与资源，可如此让每个系统背负更多显然是不值得的，在这种情况下如果使用微服务架构就另当别论了。

如果更进一步来讲，根据企业应用的差异性，为了达成更高的隔离性以及安全性，对资源的隔离性要求明显不同。具体来说，如果您是单一租户或者单一应用的话，刘俊辉强调，仅仅线程的隔离或者基于进程的隔离也就足够了；但如果是多租户或者对安全性要求较高，就需要花额外的资源进行更多的隔离，所以确定在微服务的场景下，容器被认为是使用较为恰当的虚拟化平台。

如果简要总结下容器的特征，其具备的独立封装性，意味着自身就包含了完整的依赖关系，就算变换位置也不会带来功能性的影响，部署的随心所欲是吸引大众的首要因素。

此外需要着重明确的一点，微服务架构可以被认为是小的、独立的积木搭建而来，但并不是一个简单的堆叠，这主要取决于服务架构的动态性以及相互关联的关系，所以基于微服务应用，需要做到除了创建大量服务之外，很重要的一点则是对微服务进行全面有效的管理，也就是编排（orchestration）。

据了解，目前这种管理会涉及到全生命周期的应用，例如创建时间、删除时间等；另外还有可靠性管理以及可用性管理，例如服务出现问题是否可以做到自动恢复、通过怎样的机制保证其可用性等。

除此之外就是策略管理，即那些管理可以无条件访问哪些 服务，这是对安全性的基本保障；最后一方面则是性能管理，涉及到资源的种类以及如何被提供等细节。

“关于编排的最后一点就是弹性，可以伴随负载进行扩展以及收缩，这企业应用十分关心的问题之一。作为应用开发人员，如果过度关注这方面以及运维工作，很大程度上就无法集中注意力在应用研发的其他领域，这也是微服务架构甚至是容器着力改变的现实之一。”他补充道。

从微服务到容器再过渡到具体的Kubernetes，刘俊辉对开发者们表示，之所以如此风靡，主要还是解决了两个十分关键的问题：首先将用户对基础设施的关心与应用的构建完全剥离开，Kubernetes完全可以承担对基础设施的管理；此外整个应用过程的动态性很好地被Kubernetes掌控以及概括，为用户提供了最终状态的保证。

大家都知道，容器以动态、可靠以及弹性著称，具体来说Kubernetes又是如何通过分离平台和应用来显示以上这些优势的？关于此类问题，刘俊辉认为：”完成这样的部署，主要归功于提供了开放的标准接口与基础设施对接。据了解，目前比较流行的开放接口CRI，也就是Container Runtime Interface。尽管目前比较标准的Kubernetes都使用Docker Runtime，但可以把它换成任何的Runtime，完全没问题；此外如今在Kubernetes的生态圈中网络插件的资源十分丰富，选择较多。“

从演讲中我们得知，目前来看云原生平台发展的趋势可以被概括为几个方面，分别是全托管的Kubernetes服务以及更多的Kubernetes开放的接口；还有面向特定领域的云原生平台等。

类比一下，我们知道如今的高开发级语言可不止是JAVA以及Python，为什么会有这么多语言呢？主要还是因为不同的语言在特定的场景下会显示出特定的优势。

针对特定领域的应用平台，不同的应用领域需要专门的能力，例如IOT和边缘计算，本身就与大规模的网站应用、互联网应用是完全不同的；上个月发布的K3S平台，主要应用于跟踪Kubernetes并对其进行一些精简，如果将其应用在边缘计算等资源受限的场景中就会比较适合。

”关于Kubernetes服务，其实京东云所做的实践被叫做JCS Kubernetes，并且已经通过CNCF的一致性认证，这表示在其他已经通过一致性认证的Kubernetes平台所部属的业务，可以百分百部署在京东云Kubernetes集群服务商，无须关心平台运维，只要细心把控应用即可。“他补充道。除了上述提及的插件系列之外，关于计算、网络以及存储的基础设施服务部分，还有一些其他的通用应用服务在列，例如数据库服务；基于身份、基于租户认证以及访问权限的管理；涉及监控、告警以及跨云部署等方面，其中高效完成业务在不同平台之间的迁移工作也十分关键。

云原生与微服务架构（京东云专家架构师 王碧波）

聊毕容器，王碧波作为本场沙龙的第二位分享嘉宾，为开发者们现场带来了主题为“云原生与微服务架构”的技术演讲。从微服务的基本概念着眼，王碧波简要总结道，微服务通俗点儿来说就是提倡一个服务系统中不要被迫容纳太多功能，最好是比较独立的一组，将开发、部署、扩展等定义为一个单元来进行操作，整体来看很简单。

咋一看，这样的构想以及操作很简易，但实际上远不是想象的那样，在服务运行的过程中会产生很依赖，此外调用关系需要十分细致的梳理，关于服务状态以及生命周期管理也会一并变得极为复杂。

由此痛点引申到一个好的微服务架构应该具备哪些功能？”其实总结来看主要包括四个方面能力，关乎整个生命周期的过程管理；微服务场景下功能实现的辅助；功能之间相互调用的能力以及在整个微服务系统中做运行观测的能力等。”比方说为了系统的考虑，大家都希望有些设计可以服务本地，在本地部署缓存；但是当数据发生变更的时候，本地缓存的机制更新如何被设计就是个问题，也是经常容易出现bug的地方，这种事情就是微服务框架应该着重思考的。

进一步说明，目前市面上常见的微服务架构首先要数Dubbo。它本质上是一个高性能的RPC框架，并不算是完整的微服务框架，功能上比较偏重于RPC调用相关的一些能力，如果选择采用Dubbo，实际上还需要在周边扩充很多其他项目进入才能起到一个完整微服务架构的作用。

第二个代表性的则是腾讯开源的微服务架构叫Tars。相比而言，它的功能要比Dubbo完整很多，可以看到Registry，即关于路由和流量的管理；patch，关于微服务一些部署发布，还涉及到配置、日志、调用统计等详细信息。

此外，它本身也支持多种开发语言以及架构，算是一个比较完整的服务治理框架，从功能上来说基本各个维度都有考虑涉及，直接使用可以解决不少问题，但与目前的开源框架以及开源生态相融合、相比较就作用一般化了。

另外还有一种，名叫Spring Cloud。具备统一的规范以及接口，背后支持多种不同且具体的服务，且本身与Kubernetes没有任何冲突。

谈及最近红火的服务网格，王碧波认为，服务网格最大的特点就是通过引入网络代理，时业务活力和服务治理彻底切分；并且，所有的策略调整都以一个动态的配置变更方式来实现，而不是采用变动代码的方式，进而实现一种业务逻辑与服务治理彻底被切分的状态，目前可以提及的Kong Mesh就是服务网格的具体架构实现，也是代表性的微服务架构之一。

Kong Mesh是一个比较简单的服务网格实现。Kong Mesh在控制面中涉及到一个管理集群，有关微服务的相关治理策略都会通过配置的方式写入数据库中，而每个服务旁都会部署一个Kong的代理服务，会到数据库中读取配置好的服务治理逻辑然后加以处理。据了解，之前的Kong相当于本身就是一个有关API网关的开源项目，后来被应用到服务网格中，所以据实测其网格调用的服务能力非常强悍；另外Kong的系统组建十分简单，表现为依附，架构简单且实践起来较为便捷，本身又是基于openresty相关，易于开发扩展。

但王碧波强调，这并不代表高可用的Kong没有缺陷。一方面，控制面的能力并不丰富；另一方面，生态圈本身不强大，主要还是以Kubernetes插件的方式扩展，开源生态十分欠缺。

开发者们普遍感兴趣一点，未来云原生在微服务方面究竟会有怎样的考量与部署？值得肯定的是，云原生天然就是作用于微服务架构的，可以视作一个服务微服务架构的生态系统，而其中会以容器的编排作为重要的手段之一。具体着眼于几个重点项目的情况，会涉及例如Kubernetes服务弹性的管理、Prometheus监控、envoy服务调用的代理、CoreDNS服务发现以及containerd运行环境等。

“简单介绍下Envoy。使用者众多；大量项目集成的对象，比方说最火的服务网格Istio；本质上是一个网络代理，你可能会疑惑，如今最知名的网络代理明明是Nginx，为什么还需要Envoy这呢？最关键的在于在服务网格时代，人们希望所有的配置都可以达成动态下发，而不是去手动修改代码再统一上线操作，Envoy基于API动态配置恰好实现了这个想法。“

另外关于Prometheus这个完整的监控方案，他总结道，这款监控方案将数据查询、预警报警等全部整合在其中，与其他监控方案存在差别的地方主要集中在部署、SDK等方面。首先从部署层面来说，监控方案本身就是包含一个TSDDTSDB，自带数据库降低了部署难度；此外提供的SDK，很容易产生符合规范的商标指标数据；更重要的一点，其他监控方案主要采用主动上报的方式，而Prometheus以拉取形式为主，即一旦产生符合规范的数据，只要具备一个可供拉取的地址就可以完成服务端拉取的策略，比较实时性；关于Opentracing，实际就是API规范等。

再说说近两年特别火的Istio。之前多次提及”服务网格“，Istio本身就是一个非常完整的服务网格方案，也分为数据面以及控制面。数据面也是服务旁会设置一个代理来接管流量；而控制面会区分细致，其中Pilot，主要负责流量管理策略以及管理下发；Mixer的核心在于，调用之前判断是否有权限；流量真正调用之后完成与此有关的信息收集等；另外还涉及到Citadel，主要用作调用安全方面相关项目，主要在于证书管理。

王碧波强调，目前关于服务治理层面，所存在的最大问题其实是一种纠结：现在究竟要不要”上马“服务网格呢？需要明确的一点，服务网格确实可以将业务逻辑和服务治理完全独立，并促使服务治理、变成动态分配的情况，这一点 的实现同语言以及架构均无关系；但架构复杂性以及性能损耗等是不容忽视的问题。

所以是否采用服务网格，他提出了几点判断：首先还是自身在基础架构方面是否有比较强悍的技术能力；”上马“服务网格是好事儿，但需要综合考虑服务治理能力提升的紧迫性以及所带来的业务架构的复杂度；更重要的一点，这种动态的治理能力与服务的处理性能哪个比较关键，也是亟需明确的事儿非常重要的权衡角度。

谈及微服务架构的选择，根据企业情况不同主要可以归为几种：首先是完全自研的选择，比较适合基础架构研发能力特别强的大型公司；其次直接上手一些开源的框架，这对于大多数公司都是比较适合的；第三种选择，使用公有云提供的微服务框架；另外，开源/资源+公有云结合的方式也是非常不错的一种选择。

据了解，京东云在微服务架构方面有一些产品十分值得提及，例如关于全生命周期管理的Kubernetes的集群；具备超级弹性伸缩、高可用还满足云部署等需求的DevOps；在功能实现方面主要包括API网关、函数服务、消息队列、对象存储等产品组件；如果着眼运行观测，日志服务、监控、调用链关系以及调用服务等更是必不可少。另外，京东云分布式服务框架产品旨在整合微服务相关的各种产品模块提供统一的微服务平台。

分享尾声，王碧波还未现场开发者解说了利用京东云现提供的组件来搭建自己的微服务架构所涉及的详尽过程。”首先服务如果能够被外部调用，需要经过API网关完成一些关于接口安全以及管控的事情；随后流量通过负载均衡服务进入VPC中；当服务需要部署的时候，可以通过云部署的方式将服务部署在高可用组上，完成后会下发一些与分布式服务相关的配置到应用中；之后就会自动关联到京东云的注册中心，去做服务发现，进而就可以采用京东云的配置中心去完成配置并管理数据等。“

现场精彩分享仍在继续，开发者互动气氛活跃。话说，Serverless的官方定义是啥？为什么Serverless这么火？有什么突出之处？究竟应该如何打造自己的Serverless服务，有标准或者范式可以参考吗？

在关于Serverless的分享中，京东云技术专家张金柱提到，“这是云时代的一种架构思想。如今给大家提供了非常丰富的开发框架以及技术组件，时代很赞；此外云计算将大量的社会资源，例如计算以及存储资源集中到一起形成规模效应，这两点果断成就了Serverless。”

云原生下的Serverless浅谈（京东云技术专家  张金柱）

此外他还认为，从IaaS过渡到微服务以及现在的Serverless，云计算让业务人员不用过多担心技术，而是专注业务；如果从软件架构发展的角度，单体结构发展到微服务以及分布式，这都是必然的技术迭代。“我们可以简单认定一点，Serverless是云SaaS，是一种抽象。得益于底层的标准化，让Serverless成为一种可能。”他进一步补充道。

Serverless，作为云计算进入深水期的表现，被誉为如见架构发展的必然结果，谈及落地应用，张金柱总结道，主要体现之一在于应用后端，例如物联网。

比方说在风力发电的场景中，风车会伴随天气、风向等因素产生差异，为了达到更高的发电效率就需要调整风车方向。”风扇上传的数据到云端是固定频率的，其中包括数据处理部分模型，如果此时使用Function来处理，基本上符合Serverless适用的场景。首先读取存在的数据；假设当地空气、风向的数值，再根据当前的风向去做一个调整并发出指令，传回终端；完成实时的数据处理，例如一些大文件处理以及流数据处理等。“

又例如AI场景中针对视频和图片的分析和处理，这可能会涉及图片建模以及压缩手段。一张图片，需要根据设备不同来调整大小甚至形状，这样的需求在过去的基础架构上很难完成，过程复杂。但在Serverless中，只需要将图片上传至对象存储，然后去处理预先定义好的Function，按照需求剪裁成不同设备所需要的尺寸并回传存储，这个过程需要避免死循环出现，会有一些执行时间的限定。

此外，FaaS作为Serverless架构实现的方式之一，首先是无状态的，能够无状态中实现水平扩展，相对来讲更容易一些。这时FaaS像强力胶水一样，连接各种云上服务，让用户更轻松构建自己的业务系统，实现高可用、可扩展、经济实用的架构。而其中被定义的BaaS，会作为FaaS层的外置状态，或者持久化数据基本组件，例如原来需要数据库或者一些消息队列需求等，现在可以统统交给云厂商或者第三方服务，这些服务基本上多以API方式提供，用户无需关心底层的扩容、缩容问题。

不可避免，Cloud Native确实对Serverless产生了影响，对于Serverless这个只属于云时代的架构思想，规模化以及更加标准的方式、所提供的无上限的资源为其弹性的伸缩提供了基础。此外，云计算将一些基础细节加以隐藏，这不单单是应用架构方面，当然还涉及到PaaS服务。

”谈到Serverless的标准和范式的时候，主要由于其标准和架构层面的很多问题均处于探讨之中，甚至还没有方法论，所以也就谈不上标准以及范式了。“他说。

最后关于Serverless的挑战和未来，张金柱引用了伯克利给出的两个重要总结，其实现在的Serverless有两大退步：忽略了数据，或者说数据处理的要求；天然的无状态对于分布式并不友好，例如一致性问题以及事务性问题的出现等。

云原生时代数据库的发展趋势（PingCAP 联合创始人兼 CEO  刘奇）

在有关“云原生时代数据库的发展趋势 ”的主题分享中，刘奇认为如今的Cloud Native定义的关键在于用容器去Package everything，还有就是使用微服务。

此外，存储与计算分离的思想在针对TiDB的技术实践中也有所印证。TiDB目前做的一些关于Computing的实践，很有意思的点就是每一层都可以做成Computing。如果综合去看其中的差异，其实TiDB是被当成计算上的Computing来实现支持，相当于被做成插件，如此形式在计算层可以，在存储层也可以，而存储层实现多个插件，这样一来整体结构的灵活性就会体现的非常好。

需要强调的一点，采用何种技术改变，其核心的思想主要在于用户关注的是更高级别的业务层面，因为这个因素会左右最后的选择。

云原生从技术角度看不免涉及计算、存储、网络等范围甚广、学习以及实践的难度不小，但却可以发挥重要作用。从产业角度看，可以显著提升传统企业的IT部署效率，助力数字化升级，为企业赢得快速发展的机遇，好处颇多……京东云技术沙龙关于云原生的探讨虽然暂时告一段落，但企业关于K8S、无服务器、开源等的深入探索似乎才刚刚开始！

点击阅读原文了解更多。