2018-08-14 15:30
大家好，我叫牛秋霖，来自于阿里巴巴中间件。一提到阿里双十一大家都清楚，双十一涉及到所有应用，绝大部分的应用都是无状态的，所有的状态都是存储在后台的数据库或者中间件中。
我来之前没有那么了解，我这里说的更偏向于互联网这块怎么说，我们这里不会特别提容器化的具体细节，会提到容器化下一步具体怎么走。
我通过四个部分说一下：第一我们来看一下我们定义中的有状态都是什么，什么样的算是有状态。第二看一下云原生的定义以及它有哪些关键的技术。第三部分我们通过一个例子看一下云原生到底能够给我们带来什么。最后我们看一下云原生最后走到一个什么方向。
有状态应用，这里列举了其中比较重要的两种，一种是每一个实例在集群中有一个唯一的身份标识，另外是有数据存储的，他们在本地是有数据存储的，如果数据存储丢失对它来说有是有损的。还有串链接，串链接如果断了也是有损的。
我们看看在云原生的状态下我们到底怎么玩。云原生技术能够帮助公司和机构在公有云、私有云和混合云等新型动态的环境中创建和运行可弹性扩展的应用。这里面有几个典型代表的技术，容器技术、服务网格、微服务架构、不可变的基础设施以及声明试API设计这些技术让构建富有韧性、易于管理、便于观察的松耦合系统成为可能。这里面提到了几个关键的技术，第一，提到了不可变的基础设施，我们要保证稳定性首先基础设施一定要在可控的范围之内；第二使用了容器技术；第三，使用了声明式API，它的好处会具体介绍一下；第四有健壮的自动化手段，通过自动化手段才能帮助我们做那些事情。
接下来我们分别看一下每个技术。
不可变的基础设施，这不是具体的技术，是一种理念，在传统的模式下想安装一个自己的应用，这个时候我们自己的一个服务依赖了A和B两个软件，我们安装的时候A是1.0，B是2.5，运行了一段时间，服务有增长需要扩容，又扩容一个实例，新的实例A是1.1，B是2.6.1，对于线上服务来讲我们所依赖的环境发生了变化，对于我们线上服务是一个很大的风险。我们又去做一次扩容，A和B的版本又变了，对我们服务稳定性是一个危险。
在Docker状态下，通过一个镜像启动容器，所有实例的环境都是一样的，我们解决了环境不可变，对我们带说是稳定的。在上比较重要的业务的时候，我们会在测试环境做一个比较完善的测试，但是这个比较完善的测试不可能把我们所有依赖的软件排列组合所有的可能性都去测一遍，我们只是测比较稳定的几个场景。
通过这种方式我们把测试的验证过的稳定的环境搬到线上去，保证线上环境稳定性。过一段时间想对线上服务进行升级，我们就做一个新的镜像，用新的镜像做升级就可以了。比如如果在阿里云上玩这个东西，可以用ECS，通过同一个镜像创建出来的所有的ECS，操作系统和操作系统的软件是完全一致的。还有VMWare等等这些技术都可以做到。
这里面提到Kubernetes，提到云原生，离不开一个编排系统就是Kubernetes，各种节点的管理器通过一种叫Listwatch的机制进行连接。我们创建服务来说明，这个服务有三个实例，我们提交一个建立一个配置，把配置提交到服务器里面去，不需要告诉它创建三个实例，不需要告诉每个实例的配置是什么，所有的东西都在提交的配置里面去了，把配置提交里面去。所以整个这一套的机制我们首先可以体会到是一套自动化的流程，不需要手工干预，第二我们提交上去的配置完全是声明式的，只需要达到什么状态，不需要告诉怎么做，就可以把这个事情完成了。
在这里，Kubernetes里面有一个Pod的概念。LivenessProbe，会通过探测器看当前的容器是不是活着，如果不是活着的状态可以重启容器。还有可以检验容器是否对外提供服务，如果所有的容器都对外提供服务了，就认为这个Pod是可以提供服务的。PreStop，我在停止这个容器之前需要执行一些动作，保证这个业务是正常的而不是强制把它Kill掉，比如马赛克集群，刚刚大家说我们DB在一个集群中被摘掉，保证服务不会打到这里面来，这对于用户来说是最安全的。
向往上提供服务还要通过Service的方式，可以认为是一种路由的规则，Service往上可以跟负载均衡打通，负载均衡怎么知道关联哪个Pod的呢？可以通过红色的内网知道这一组Pod可以对它提供服务，怎么知道那些Pod启动是否成功呢？就通过Ready的状态下。通过这个更能够体现出它的自动化的效率，可以自动把它摘下来或者摘上去这样等等一系列的架构。
说到微服务架构，从单体应用拆分为微服务，大家都听过都知道。我们理想中的微服务是这样的，每个微服务非常简单，每个微服务是低耦合的，我的服务部管是重启和恢复对你都没有什么影响的，每个微服务之间可以使用不同的语言跨不同的平台，这些都是无所谓的，只要保证我的服务是正常的，还有高可靠、可扩展、简化部署，这都是理想化的状态。
还要解决监控的问题，我要知道B有哪些实例可以服务、哪些实例不可以服务，如果不可以服务就不要调度到它上面去。B有多少灰度是需要到新版本，有多少灰度是老版本，这都需要控制。还有超时延迟，这个超时大家都比较理解，A调用B网络不通，是不是要重试，大家都做一个同样的事情就是重复建设。所以社区给出了一个解决方案就是服务网格，所谓的服务网格就是把刚才说到的共性的问题摘出来放在一个单独的容器里面去解决，或者一个单独的服务去解决，这样一套都是基于Kubernetes的，有了Kubernetes这些都成为可能。
Sidecar是另外解决供应性的服务，两个部署在不同的Pod里面，就像之前提到的一个Pod里面可以有两个容器。
这里面我们以灰度为例，A调度B的时候，服务网格社区里面有一个解决开源的软件，我们这里以这个开源软件架构为说明，A不知道谁调用它，A把请求转到B上，响应请求然后返回。服务发现以及服务的灰度都是Envoy这一层做的，我们只需要管理这一层。B是在做流量灰度，新的版本是2.0，只有1%的流量，旧的版本是1.5，切了99%的流量。你有新的版本灰度最好先用小流量去切入，这是服务网格带来的便利性。
刚才我们从上往下说，这次我们从下往上说。首先我们开发一个应用，这个应用有微服务架构，有很多问题，我们通过服务网格解决这些问题，服务网格依赖于自动化比较高的编排系统，这就是Kubernetes，Kubernetes运行的这些都是依赖于容器技术，还依赖于虚拟化技术，再往下就是虚拟机、共享存储、SDN，再往下就是硬件。在公有云就是云厂商做的事情，再往上解决了应用池的问题。Dubbo是阿里开源的、对外的。
ETCD集群，这个都是开源的大家都清楚，所以我用它来进行说明，如果我们在传统的模式下想要串联出一个ETCD集群，我们都知道每一个节点需要知道另外两个节点的IP地址和服务端口，把这个配进去的话，在启动服务之前就需要知道其他的实例的IP地址，不管我们用Swarm还是别的，通用的做法就是创建容器，对容器进行升级，升级的时候启动创建的集群出来，这一步需要我们手动去做。
另外我们的服务还需要通过一个LB提供服务，如果我有一个实例ID坏掉了，这个机器就无法恢复了，需要换一个Mumber，这时候提醒调用方，换一个IP地址。所以机器故障需要手工替换。机器故障到时实例数据丢失。对于ETCD来讲，启动一个新的实例这个数据的拷贝还是有一定的工作量的。
云原生模式下如何应用，我们用Statefulset去解决，在这个情况下建立POD每一个POD都有一个名字的，按号标注。ETCD模式通过号推断其他实例的名字，就相当于做DNS解析，起到了这样的作用，通过这个名字就可以帮助你解析到对方的IP地址，通过这种方式解决了发现对方的问题，不管是ETCD还是ZK，可以在创建的时候把这个集群解决起来。
另外一点是Service，不单单把这些POD集合在一起，可以和云原生下的负载均衡去打通。比如在阿里云上做这个事情，创建出一个Service，如果某一个实例有问题，也可以自动地把这个服务摘掉，这些所有的都是自动化去完成的，不需要手动去操作。手动就是把机制建立起来，其他的事情就交给它自己去做了。
在云原生情况下，有共享存储，如果当这个实例真的损失的话，没关系，我们实例在共享存储里面，在Kubernetes创建新的实例，把共享存储创建在新的实例下，立刻就恢复了。
最后是Operator，它可以允许我们编程，它是一种理念，我们可以按照这种理念去编程。如果我们发现我们节点数不够了，甚至可以通过Kubernetes自动加入到集群里面，用ETCD集群自动恢复，所有的这些都是自动化的。
在原始的模式下，我们需要手动做这些事情，我们需要把每个操作印在自己的脑子里面，在云原生的情况下，所有的资源都是通过这个来做的，我们可以自动化地做这个事情。三到五年之后，传统行业不太好说，至少在互联网行业运维会失业的。互联网公司对这些运维的角色需要越来越少了，所以说失业已经进行了一拨了。
如果我们以司机为例和工程师做对比，专职司机有驾驶技术，是给老板开车的，工程师有各种技术技能，我们是给公司提供服务的，作为一个司机我们要能开不同的车，老板有什么车就开什么车。作为工程师要学习不同的技能，要保证线上业务的正常。做司机 需要给车加油，去保养汽车、洗车等等这些事情，作为工程师，要上下线、升级、配置变更、扩缩容。司机接送家人、老板客户，工程师在公司支持、在家支持在酒吧支持。司机的话，老板不休假，司机没有正常的假期，工程师也是一样的，我们是跟着线上业务一起跑的。
如果用司机做比喻，我们发现已经有部分司机开始失业了，因为开始有无人驾驶了，无人驾驶技术已经出现，而且在美国一些城市已经实行了。云原生也是这样，有状态应用、无状态应用全部打造成云原生应用，也没有运维这些人的事了，运维就是生产无人驾驶汽车就行了，就是我们深入业务做这些事情，其实运维就是无人驾驶汽车的厂商，可以这样理解。
我的分享就到这里，谢谢大家。