云原生java的那些事儿

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

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

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

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

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

Dubbo是点对点的服务框架，所有的服务都会注册到一个注册中心，由注册中心负责服务发现，然后由服务的消费者去做负载均衡。其实Dubbo的服务者和消费者只要互相发现了对方就会直接的去建立一个点对点的连接，所以有很高的性能。

Dubbo的另一个优势就是完全透明化的调用，在本地调用方法和在Dubbo中调用时完全看不出区别的，因此无需去关注本地化还是透明化。

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

由于Spring Cloud的关注点并没有在点对点的连接上，而是使用Rest API这样的APP形式调用，因此在性能上会稍微低一些，但在服务治理方面的性能就要强很多。

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

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

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

由于不是所有的程序都能够无缝的在云平台运行，所以做云原生的程序就要满足云原生的十二要素。这些要素不会对程序进行本质上的修改，而是从另一方面进行提升，使得程序能够更容易的解除无状态的应用，同时方便随处部署和扩容。

这一层所做的首先是调度，就是决定资源和应用的组合，当应用获得资源后才会真正的去运行。另一方面是编排，也就是将调度按照自己的期望去运行。

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

Linkerd的所有服务不再是由中心节点去控制，并且它也不和服务部署在一起。从上图我们可以看出所有的服务都是通过代理方式访问，比如要通过A去访问B时，不会像Dubbo一样去直连，而是由A访问本机的Linkerd，再由这个Linkerd去连接B上的Linkerd，最后由B上的Linkerd去转发给B。这个过程中所有的代理都是由Linkerd控制，它能够将所有的流量都控制住，并且它还是完全跨语言的。

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

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

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