视频课程 | 云原生与微服务架构

京东云开发者社区在3月底于北京举行了以“Cloud Native时代的应用之路与开源创新”为主题的技术沙龙，现场多位技术大咖与开发者们面对面就Cloud Native进行了深刻交流，探讨涉及容器、开源数据库等诸多技术层面的问题。

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

咱们将整理后的视频及内容资料在这里分享给你们，没能到场的小伙伴能够经过这些资料来学习和了解课程内容。

沙龙内容概要

沙龙活动重点聚焦云原生时代下，容器、微服务、Serverless以及数据库等技术应用与开源创新，同时高度结合京东云在Cloud Native以及开源领域的核心技术与一系列成功实践为开发者们进行答疑解惑！

如下是沙龙第二部分分享的所有内容，但愿能给各位开发者带来帮助：

云原生与微服务架构

—— 京东云专家架构师   王碧波——

（建议在Wi-Fi环境下观看）

https://v.qq.com/x/page/t0856s6qgbg.html?start=undefined

01微服务架构概述

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

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

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

02

常见微服务架构

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

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

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

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

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

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

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

03云原平生台的将来

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

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

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

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

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

04拥抱微服务

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

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

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

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

*以上为沙龙第二部分的内容！Enjoy

欢迎点击“连接”了解更多精彩内容

点击下方“阅读原文”得到完整PPT

·END·

阅读原文