云原生java的那些事儿

内容来源：2017年12月16日，京东金融数据研发负责人张亮在“数人云Meetup | 下一代微服务：ServiceMesh Is Coming”进行《云原生java的那些事儿》演讲分享。IT 大咖说（微信id：itdakashuo）做为独家视频合做方，经主办方和讲者审阅受权发布。

阅读字数：2512 | 7分钟阅读

嘉宾演讲视频及PPT回顾： suo.im/4NIdmt

摘要

在微服务概念大行其道的今天，Java无疑是相关生态体系最为完善开发语言。但云原生概念的出现，更增强调异构语言的无差别化开发。那么Java的强大生态体系该如何与云原生对接，又应该作哪些取舍，最终的发展趋势如何？本次将分享一些个人见解。

技术的演化缘由

规模的增加是带来技术演化的最主要缘由，由此也带来了各方面的变化。原来适应小规模的架构设计、开发框架、运维模式，在规模逐渐增大的现状下都须要进行从新的规划。

技术的演化方向

在架构设计上咱们一开始关注的是分层，思考的是如何在开发中将业务系统进行分层，使得业务可以解耦，易于维护。再进一步就是SOA，将原先的系统变为服务化的系统，由系统内部的访问变成跨系统的服务访问。而如今更多使用的是微服务，将服务拆分的更加复杂，经过微服务去提供系统之间的交互和架构设计。

开发框架则由原来的单体式过分为分布式，到如今的云时代，大部分互联网公司都在使用混合云或者公有云，云原生的开发框架也就应运而生。

运维模式从最开始的脚本化，只是在Linux上去写shell，而后上线部署基础原件。以后发展到了工具化，经过一些工具进行更加自动化的处理。到如今彻底自动化已被实现。

单体式架构 -> 分布式架构

上图表示是由阿里开源出来的Dubbo，是一个SOA的服务化框架，它能够完成从单体式框架到垂直扩展的框架再到彻底的分布式服务的拆分。

Dubbo是点对点的服务框架，全部的服务都会注册到一个注册中心，由注册中心负责服务发现，而后由服务的消费者去作负载均衡。其实Dubbo的服务者和消费者只要互相发现了对方就会直接的去创建一个点对点的链接，因此有很高的性能。

Dubbo的另外一个优点就是彻底透明化的调用，在本地调用方法和在Dubbo中调用时彻底看不出区别的，所以无需去关注本地化仍是透明化。

云原生首映——Spring Cloud

Spring Cloud提供了整套的服务化技术栈，它和Dubbo的关注点不同，做为一个服务治理框架所包含范围比Dubbo更广。而Dubbo是有着服务治理功能的RPC框架，关注的重点是RPC和通讯这块。

因为Spring Cloud的关注点并无在点对点的链接上，而是使用Rest API这样的APP形式调用，所以在性能上会稍微低一些，但在服务治理方面的性能就要强不少。

运维模式改变 – 容器+编排（K8S）

K8S被分为master和node节点，实际干活的是node，master则是用来控制执行。Spring Cloud所涉及的部分，Kubernetes都会包含。这其中进程的隔离Kubernetes能经过容器去完成，而Spring Cloud对这方面就无能为力，另外环境和资源的管理Spring Cloud也没法处理。

能够看出Kubernetes更多的是偏向于运维，它将运维的模式集成的更自动化。

云原生是一种模式

云原生实际上是一种模式，它要求更高的可用性和伸缩性，也就是要求应用永远不会挂掉，而且可以自动的针对流量进行扩容。另外还须要实现自动化的部署和管理，好比定时的代码上线之类的，无需运维手动的去执行脚本。最后要求达到效率提高和随处运行的目标。

云原生十二要素

因为不是全部的程序都可以无缝的在云平台运行，因此作云原生的程序就要知足云原生的十二要素。这些要素不会对程序进行本质上的修改，而是从另外一方面进行提高，使得程序可以更容易的解除无状态的应用，同时方便随处部署和扩容。

云原生全景图

编排领域

这一层所作的首先是调度，就是决定资源和应用的组合，当应用得到资源后才会真正的去运行。另外一方面是编排，也就是将调度按照本身的指望去运行。

服务治理领域

上图中linkerd是最早提出来的Service Mesh概念的产品。而GRPC是一个跨语言而且是彻底基于HTTP2协议RPC的框架，它经过双向不受干扰的长链接进行交互。

Service Mesh – Linkerd

Linkerd的全部服务再也不是由中心节点去控制，而且它也不和服务部署在一块儿。从上图咱们能够看出全部的服务都是经过代理方式访问，好比要经过A去访问B时，不会像Dubbo同样去直连，而是由A访问本机的Linkerd，再由这个Linkerd去链接B上的Linkerd，最后由B上的Linkerd去转发给B。这个过程当中全部的代理都是由Linkerd控制，它可以将全部的流量都控制住，而且它仍是彻底跨语言的。

Service Mesh – Istio

Istio将服务治理分为了两部分，一部分是数据面板，另外一部分是控制面板。数据面板主要是处理服务治理、服务发现以及网络之间的调用，也就是真正用来干活的。而控制面板又被分为3大块，pilot是用来进行任务调度用的，Mixer可以经过简单的编程接口去实现一些功能，好比黑白名单之类的，Istio-Auth则是一个权限的控制，可以将网络流量彻底控制在控制面板内。

开发和运维模式的改变

运维模式向自动化和可视化发展，无需再手动进行操做而且能经过控制面板直接查看到流量的大体状况。开发模式则会更关注业务自己胜于功能性需求，调试模式也发生了改变，开发人员没法再直接的登陆到线上环境查看应用状态，而只能经过遥感的方式操做。

将来的趋势

单机的操做系统将会被抛弃，取而代之的是容器调度加编排的云操做系统。裸机或者虚拟机的运行时也将会被容器取代。通讯方面将会使用Service Mesh。