“基础设施的云化、核心技术的互联网化、应用的数据化和智能化”是云的三大趋势和核心价值所在。
—— 行癫观点
在年初的阿里云北京峰会上，阿里云新任掌门行癫张建峰的首次亮相，提出了升级以后的阿里云智能意味着：
- 基础设施的云化
- 核心技术的互联网化
- 应用的数据化和智能化
前面的《看云栖说云栖》讲的大多都是和基础设施的云化相关的内容，而这次的内容还和核心技术的互联网化有关。
本文内容提取自2019杭州云栖大会《容器专场》、《云原生开发者峰会》。
先从《容器专场》开始，Kubernetes已经成为云原生应用底层平台的事实标志，当下互联网核心技术体系的基础平台。今天再去谈容器，讲的多半还是和Kubernetes有关的内容。在这次云栖大会上，阿里云发布了阿里云Kubernetes服务（ACK）2.0版，这个版本的“新”体现在：
- 新基石、ACK实现了全球化部署，并且支持边缘节点，在ACK2.0中集成了对边缘计算节点的管控、打通了混合云架构，交付效率3倍提升。
- 新算力、可在一分钟内实现上千个节点的伸缩、支持GPU等异构计算资源、提供沙箱容器选项，增加容器平台安全性。
- 新生态、集成了容器应用市场，基于ACK的应用部署更加便捷，提供合作伙伴计划助力生态建设。
在容器专场的最后，是由蚂蚁金服的专家和阿里云的专家介绍了安全容器的关键技术、kata-container、和阿里云的沙箱容器。目前，沙箱容器已经在阿里云ACK服务上线提供公测，适合对容器平台安全有更高要求的客户使用，在创建集群时勾选沙箱容器选项即可。
在《云原生开发者峰会》，阿里巴巴介绍了自己的云原生实践：
- 阿里巴巴容器集群节点超十万、容器组超百万，可能已经是全球最大规模的云原生应用实践者了。
- 因为引入云原生技术，双11 IT成本下降75%，日常IT成本下降30%。
- 目前整个阿里经济体都运行在阿里云上。
作为CNCF（云原生计算基金会）的9位TOC（技术监督委员会成员）之一，阿里云李响做了《阿里巴巴的云原生之路》的演讲。阿里选择云原生的理由可以总结为三个方面：
- 资源效率、利用容器可以提升资源利用率，提高调度效率，尤其是在阿里巴巴大量使用了离线业务和在线业务混合部署的架构，利用在线业务系统的闲置时段进行离线计算。
- 开发效率、程序开发人员和运维人员利用容器和编排系统可以更好的协作，更易于实现CI/CD，基于服务网格可以让多语言环境的微服务系统更易于构建和运维。
- 标准与开放、基于共同的开放标准，行业生态伙伴更容易进行协同技术演进。
什么是CNCF：云原生计算基金会构建可持续的生态系统，并培育社区，以支持云原生开源软件的增长和健康。
CNCF下的开源项目包括：
- Kubernetes ：集群中管理跨多台主机容器化应用的开源系统；
- Prometheus ：专注于时间序列数据，为客户端依赖及第三方数据消费提供广泛集成支持的开源监控解决方案；
- OpenTracing：与厂商无关的分布式追踪开源标准；
- Fluentd：创建统一日志层的开源数据收集器。
- Linkerd：为微服务提供可靠性支持、自动化负载均衡、服务发现和运行时可恢复性的开源“服务网格”项目；
- gRPC：现代化高性能开源远程调用框架；
- CoreDNS：快速灵活的构建 DNS 服务器的方案；
- containerd：将容器运行时及其管理功能从 Docker Daemon 剥离的镜像管理和容器执行技术；
- rkt：帮助开发者打包应用和依赖包，简化搭环境等部署工作，提高容器安全性和易用性的容器引擎。
其实不仅这些项目，符合CNCF理念的开源项目还有很多，CNCF将这些项目整合成了一张全景图：https://landscape.cncf.io/images/landscape.png
（全景图缩小版）
阿里云结合自身的使用实践，基于Kubernetes开源了OpenKruise项目，提供一组额外的Kubernetes控制器：
- BroadcastJob Controller、用于把Job跑在每一个节点上。类似于DaemonSet会在每一个节点上去运行，区别是Job会结束而Daemon会一直运行并占用资源。
- Sidecar Set、类似于Istio的Sidecar 容器自动注入，便于管理人员将日志、监控等一些业务无关的Sidecar容器的管理集中统一起来。
- Advanced StatefullSet Controller、提供StatefullSet的原地升级能力，保留pod而只对容器镜像进行升级，避免销毁pod重建对应用网络拓扑造成的冲击。
最后的内容是和微服务相关，阿里云资深技术专家司徒放（姬风）做了《微服务遇见云原生》的演讲。姬风认为微服务架构走向云原生有三个关键：
- 在kubernetes上运行、kubernets已经是云原生的事实标准、kubernetes天然为微服务设计、kubernetes为分布式、可弹性扩缩容应用提供运维支持。
- 基于Service Mesh治理、Service Mesh提供多语言异构技术栈的统一监控、智能、Service Mesh通用组建与业务逻辑完全解耦，独立升级、但Service Mesh尚未完全成熟，待提升规模化能力、需进一步提升兼容性、性能。
- 应用Serverless化、Serverless 不等于FaaS，阿里云应用引擎SAE在不需要对应用作大量修改的同时即可享受到Serverless极速扩容和成本降低的好处。
基于Kubernetes来构建微服务，阿里云可以集成的服务产品包括：
- Istio & Envoy、Service Mesh的事实标准Istio 和Envoy已经是阿里云ACK（阿里云Kubernetes） 服务的内置组件。
- 日志服务SLS、阿里云日志服务提供事件安全审计、业务日志收集、ingress（kubernetes的服务路由组件）大盘。
- 应用实时监控ARMS、ARMS可与jaeger/Zipkin/Skywalking等链路追踪服务集成；Prometheus作为下一代的开源监控系统，提供了Kubernetes，数据库，消息队列，基础架构等各类技术组件的监控能力 ，ARMS提供Prometheus全托管式云服务，无需安装运维；Grafana 是一个大规模指标数据的可视化展现，是网络架构和应用分析中最流行的时序数据展示工具，提供了包括Kubernetes，主机，MySql，kafaka等各类技术的监控大盘，在阿里云上可以一键开启，并支持导入现有大盘数据。
- 链路追踪、阿里云链路追踪服务支持OpenTracing API，使用阿里云链路追踪服务可比自行构建节省80%成本。
- 微服务引擎MSE、微服务引擎 MSE（Microservice Engine ）是微服务注册中心和配置管理的全托管式平台，提供高可用且免运维的服务注册和配置管理集群，如 ZooKeeper、Nacos 和 Eureka 等。
- 企业级分布式应用EDAS、同时支持ECS和Kubernetes应用托管、支持Dubbo/Spring Cloud无侵入的微服务治理。
- 应用高可用AHAS服务、Sentinel是阿里云开源的限流降级引擎，AHAS提供Sentinel的云上版本，除了限流降级AHAS还提供架构感知和故障演练的功能。
- 应用配置管理ACM、应用配置管理 ACM（Application Configuration Management）前身为淘宝内部配置中心 Diamond，现已作为 Nacos 的配置中心模块开源。
什么是Service Mesh 服务网格？按照服务网格概念的提出者Willian Morgan（Linker 的 CEO）的定义：
A service mesh is a dedicated infrastructure layer for handling service-to-service communication. It’s responsible for the reliable delivery of requests through the complex topology of services that comprise a modern, cloud native application. In practice, the service mesh is typically implemented as an array of lightweight network proxies that are deployed alongside application code, without the application needing to be aware.
服务网格是一个用于处理服务间通信的基础设施层，它负责为构建复杂的云原生应用传递可靠的网络请求。在实践中，服务网格通常实现为一组和应用程序部署在一起的轻量级的网络代理，但对应用程序来说是透明的。
Istio 作为最流行的ServiceMesh 项目，通过自动注入的Sidecar容器来解决服务路由、安全认证、监控调度等非常重要又和业务本身无关的任务。Istio最初只支持Kubernetes。
（蓝色部分即为SideCar容器）
