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

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

原创：   京小云   京东云开发者社区    4月4日

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

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

我们将整理后的视频及内容资料在这里分享给大家，没能到场的小伙伴可以通过这些资料来学习和了解课程内容。

[strong] 沙龙内容概要 [/strong]

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

以下是沙龙 第二部分 分享的全部内容，希望能给各位开发者带来帮助：

云原生与微服务架构 

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

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

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·
 

阅读原文

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/69912185/viewspace-2644158/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/69912185/viewspace-2644158/