云原生主要技术

上一篇文章介绍了云计算和云原生，这里讲一下云原生的主要技术，主要包括容器、微服务、DevOps、ServiceMesh、ServerLess、声明式API，当然我这里并不会将具体的技术，主要还是概念相关的东西了。先上一个CNCF 生态的技术栈，前几年看的时候，没有几个，今天一看，真多啊

容器

还是先上一张PPT的截图吧，简单明了。

1、容器作为应用的集装箱，封装应用的依赖，简化应用的部署，集装箱的这个类比，戳中了众多应用开发者的痛点，在没有使用容器之前，部署一个应用+升级一个应用是非常复杂，而且也是非常容易出现问题的地方。

2、容器的隔离特性，将虚拟化的隔离特性带给应用开发者，当然这里并没有多少新的技术，还是靠Linux底层的Cgroup、Namespace、Quota等等，对这些做了封装。刚看到这个类比：我们无论什么样的开发，其实都是对接口的封装，例如我们做IAAS、PAAS平台是对vmware、Kubernetes的接口的二次开发，我们比较陌生的docker，其实是对linux接口的开发，Linux其实是对底层软硬件驱动的接口开发。。。

3、轻量级虚拟化，如果现在最火的docker 不是轻量级，估计也会沦为CloudFoundry 中DEA+warden的下场

基于比较易用的镜像能力，docker以“Build Once,Run Anywhere” 的宣传口语，一统容器江湖.

这里想说点别的,我们一直在用比喻去讲解docker 和容器,但是，大家应该比较清楚，比喻在让你利杰这个事务的时候，也让你停止了思考，其实比喻更适合对门外汉讲，我们技术人员看到的应该是这样的docker或者更详细点。

容器编排

按照云原生应用的十二要素原则，其实一个容器只能用于运行一个进程，那么对于分布式应用来说，必然需要一套编排管理工具，也就是用于容器的编排管理和运维，例如Kubernetes、Swarm、Mesos等，大部分还都是使用Kubernetes，由Google背书，并且具有丰富的网络、存储、计算扩展机制（好像容易扩展的开源项目才能活，例如IAAS领域的OpenStack），就下下图描述的宠物与家畜，电话接线员一样，Kubernetes 解决了容器管理/应用管理的问题，开发者把应用丢到K8s集群，然后访问应用即可。

管理：Kubernetes的目标是让你可以像管理牲畜一样管理你的服务，而不是像宠物一样

编排：丰富的编排策略，用户只需要创建应用与访问应用，对于应用相关的网络、存储、数据等都不需要用户管理

微服务

微服务改造意味着先选择一套大型的应用程序，然后识别出限界上下文（bounded contexts）及其内部的业务功能，并对它们进行分割，重要的是要将数据一起进行分割，也就
是说要采用应用数据库而非集成数据库。为了理解业务领域的内容，关键的一点就是要在一开始就采用上下文图（context map ）

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信---维基百科

微服务架构带来的优势：
1、各服务开发语言无关性
2、各服务编译构建部署无关性
3、服务复用（在传统厂商，这个很难，大部分的微服务还都是定制开发的）

微服务架构的两个问题:

• 服务发现：在众多的微服务组件中，服务使用者如何找到准确的微服务组件
• 负载均衡：多实例微服务，如果实现负载均衡

微服务带来的比较头大的问题，如下图，这也是云原生的下一个技术 ServiceMesh逐渐普及的原因,总结来说就是，微服务是以提高运维复杂度的代价，来提高敏捷性。是好是坏还真不好说，对于开发人员来说 有好处有坏处，好处就是开发方便，选择自己喜欢的框架和开发语言，坏处就是各个微服务交互的时候就有些问题，需要考虑的点比较多。对于运维人员来说，感觉全是坏处，原来只需要运维一个tomcat，现在需要运维N个tomcat。。。

Service Mesh

Service Mesh 服务网格是一个基础设施层，用于处理服务间通信。云原生应用有着复杂的服务拓扑，服务网格保证请求在这些拓扑中可靠地穿梭。在实际应用当中，服务网格通常是由一系列轻量级的网络代理组成的，它们与应用程序部署在一起，但对应用程序透明。

对ServiceMesh描述最好的，应该是面向容器的SideCar设计模式，这个SideCar的设计模式在ServiceMesh 还没有普及起来的时候就有人提出来了，可以看下图，通常我们第一印象就是感觉多了这个sidecar 是不是运维复杂，浪费资源等等，不过细考虑容器化的思想，其实多出来的这个sidecar只是一个进程而已。

这里安利一下istio，Istio是语言无关的服务治理框架，对ServiceMesh的架构、功能和API进行了标准化，与Kubernetes紧密结合

1. 数据平面，主要是智能代理（Enovy），即sidecar ，用于管理微服务之间的网络流入和流出，在创建微服务时，由istio自动注入该sidecar
2. 控制平面：将用户配置的路由规则，推送到sidecar，安全相关控制
   • 主要功能
   • 动态服务发现
   • 负载均衡
   • 熔断
   • 健康检查
   • 容错、监控指标
   • 灰度发布/流量控制
3. 流程：
   • 创建应用时自动注入sidecar
   • 流量拦截，pod初始化时，将业务容器的流量拦截到sidecar，sidecar将流量转到业务容器
   • 服务发现，sidecar查询istiod服务，获取服务实例列表
   • 负责均衡：sidecar根据负载均衡策略，选择服务实例
   • 流量治理：sidecar查询istiod服务，获取流量控制规则，在拦截的流量中执行流量控制
   • 访问安全：sidecar进行双向认证和通道加密
   • 服务监控：sidecar连接管理平面，将监控指标、日志、调用链发送istiod

DevOps