云原生

转载自：https://blog.csdn.net/csdnnews/article/details/90093190
    https://www.cnblogs.com/IT-Evan/p/CloudNative.html

  

前言

  自 2013 年容器（虚拟）技术（Docker）成熟后，后端的架构方式进入快速迭代的阶段，出现了很多新兴概念：

• 微服务
• k8s
• Serverless
• IaaS：基础设施服务，Infrastructure-as-a-service
• PaaS：平台服务，Platform-as-a-service
• SaaS：软件服务，Software-as-a-service
• Cloud Native： 云原生
• Service Mesh

  后端架构的变迁和云计算的发展密切相关，架构其实在不断地适应云计算，特别是云原生，被誉为未来架构，在 2019 年，云原生落地方案 Service Mesh 在国内外全面开花，我认为，未来已来。

  

后端架构演化史

集中式架构

  集中式架构又叫单体式架构，在Web2.0模式并未大规模兴起时十分流行。后来，基于Web应用的B/S（Browser/Server）架构逐渐取代了基于桌面应用的C/S（Client/Server）架构。B/S架构的后端系统大都采用集中式架构，它当时以优雅的分层设计，统一了服务器后端的开发领域。
  集中式应用分为标准的3层架构模型：数据访问层M、服务层V和逻辑控制层C。每个层之间既可以共享领域模型对象，也可以进行更加细致的拆分。
  其缺点是

• 编译时间过长;
• 回归测试周期过长;
• 开发效率降低等；
• 不利于更新技术框架

分布式系统架构

  对于互联网应用规模的迅速增长，集中式架构并无法做到无限制的提升系统的吞吐量，而分布式系统架构在理论上为吞吐量的上升提供了无限扩展的可能。因此，用于搭建互联网应用的服务器也渐渐地放弃了昂贵的小型机，转而采用大量的廉价PC服务器。

容器技术新纪元 Docker

  分布式架构的概念很早就出现，阻碍其落地的最大问题是容器技术不成熟，应用程序在云平台运行，仍然需要为不同的开发语言安装相应的运行时环境。虽然自动化运维工具可以降低环境搭建的复杂度，但仍然不能从根本上解决环境的问题。
  Docker的出现成为了软件开发行业新的分水岭；容器技术的成熟，也标志技术新纪元的开启。Docker让开发工程师可以将他们的应用和依赖封装到一个可移植的容器中。就像当年智能手机的出现改变了整个手机行业的游戏规则一样，Docker也大有席卷整个软件行业，并且进而改变行业游戏规则的趋势。通过集装箱式的封装，开发和运维都以标准化的方式发布的应用，异构语言不再是桎梏团队的枷锁。
  在 Docker 之后，微服务得以流行开来

微服务架构

  微服务架构风格是一种将一个单一应用程序开发为一组小型服务的方法，每个服务运行在自己的进程中，服务间通信采用轻量级通信机制(通常用HTTP资源API)。这些服务围绕业务能力构建并且可通过全自动部署机制独立部署。这些服务共用一个最小型的集中式的管理，服务可用不同的语言开发，使用不同的数据存储技术。
  微服务优势

• 可扩展
• 可升级
• 易维护
• 故障和资源的隔离

  世界上没有完美无缺的事物，微服务也是一样。著名软件大师，被认为是十大软件架构师之一的 Chris Richardson 曾一针见血地指出：“微服务应用是分布式系统，由此会带来固有的复杂性。开发者需要在 RPC 或者消息传递之间选择并完成进程间通讯机制。此外，他们必须写代码来处理消息传递中速度过慢或者不可用等局部失效问题。”
  在微服务架构中，一般要处理以下几类问题：

• 服务治理：弹性伸缩，故障隔离
• 流量控制：路由，熔断，限速
• 应用观测：指标度量、链式追踪

  解决方案 Spring Cloud（Netflix OSS），Spring Cloud 体系提供了服务发现、负载均衡、失效转移、动态扩容、数据分片、调用链路监控等分布式系统的核心功能，一度成为微服务的最佳实践。
  的确 SpringCloud 方案看起来很美好，但是它具有非常强的侵入性，应用代码中会包含大量的 SpringCloud 模块，而且对其他编程语言也不友好。

Kubernetes

  Kubernetes 出现就是为了解决 SpringCloud 的问题，不侵入应用层，在容器层解决问题。
  Kubernetes的目标旨在消除编排物理/虚拟计算，网络和存储基础设施的负担，并使应用程序运营商和开发人员完全将重点放在以容器为中心的原语上进行自助运营。
  Kubernetes 也提供稳定、兼容的基础（平台），用于构建定制化的 workflows 和更高级的自动化任务。 Kubernetes 具备完善的集群管理能力，包括多层次的安全防护和准入机制、多租户应用支撑能力、透明的服务注册和服务发现机制、内建负载均衡器、故障发现和自我修复能力、服务滚动升级和在线扩容、可扩展的资源自动调度机制、多粒度的资源配额管理能力。
  Kubernetes 还提供完善的管理工具，涵盖开发、部署测试、运维监控等各个环节。

Service Mesh

  Service Mesh 是对 Kubernetes 的增强，提供了更多的能力。
  2018年9月1日，Bilgin Ibryam 在 InfoQ 发表了一篇文章 Microservices in a Post-Kubernetes Era，文中作者的观点是：在后 Kubernetes 时代，服务网格（Service Mesh）技术已完全取代了使用软件库实现网络运维（例如 Hystrix 断路器）的方式。
  如果说 Kubernetes 对 Spring Cloud 开了第一枪，那么 Service Mesh 就是 Spring Cloud 的终结者。

总结

  最后我们用一个流程图来描述后端架构的发展历程

  可以看出，微服务生态这里，Spring Cloud 为代表的这条路已经后继无人了，未来属于 Service Mesh 。
  Service Mesh 经过2年的发展，目前 Service Mesh 已经足够成熟，已经有生产落地的案例，我们接下来就看看 Service Mesh，在此之前，我们要先理解一个概念，云原生。

  

云原生 Cloud Native

  如何理解“云原生”？之所以将这个话题放在前面，是因为，这是对云原生概念的最基本的理解，而这会直接影响到后续的所有认知。云原生的定义一直在发展，每个人对云原生的理解都可能不同。2018 年 CNCF (Cloud Native Computing Foundation)更新了云原生的定义。

  这是新定义中描述的代表技术，其中容器和微服务两项在不同时期的不同定义中都有出现，而服务网格这个在 2017 年才开始被社区接纳的新热点技术被非常醒目的列出来，和微服务并列，而不是我们通常认为的服务网格只是微服务在实施时的一种新的方式。
  那我们该如何理解云原生呢？我们尝试一下，将 Cloud Native 这个词汇拆开来理解，先看看什么是 Cloud。

什么是云 Cloud

  云计算的出现和虚拟化技术的发展和成熟密切相关，2000 年前后 x86 的虚拟机技术成熟后，云计算逐渐发展起来。
  基于虚拟机技术，陆续出现了 IaaS/PaaS/FaaS 等形态，以及他们的开源版本。
  2013 年 docker 出现，容器技术成熟，然后围绕容器编排一场大战，最后在 2017 年底，kubernetes 胜出。2015 年 CNCF 成立，并在近年形成了 cloud native 生态。
  在这个过程中，云的形态一直变化，可以看到：供应商提供的功能越来越多，而客户或者说应用需要自己管理的功能越来越少。

什么是原生 Native

  云原生代表着原生为云设计。详细的解释是：应用原生被设计为在云上以最佳方式运行，充分发挥云的优势。
  这个理解有点空泛，但是考虑到云原生的定义和特征在这些年间不停的变化，以及完全可以预料到的在未来的必然变化，我觉得，对云原生的理解似乎也只能回到云原生的出发点，而不是如何具体实现。

Cloud Native 是道，Service Mesh 是术

  那在这么一个云原生理解的背景下，再来介绍一下对云原生应用的设想，也就是云原生应用应该是什么样子。

  在云原生之前，底层平台负责向上提供基本运行资源。而应用需要满足业务需求和非业务需求，为了更好的代码复用，通用型好的非业务需求的实现往往会以类库和开发框架的方式提供，另外在 SOA/ 微服务时代部分功能会以后端服务的方式存在，这样在应用中就被简化为对其客户端的调用代码。然后应用将这些功能，连同自身的业务实现代码，一起打包。

  而云的出现，可以在提供各种资源之外，还提供各种能力，从而帮助应用，使得应用可以专注于业务需求的实现。非业务需求相关的功能都被移到云，或者说基础设施中去了，以及下沉到基础设施的中间件。

  以服务间通讯为例：需要实现下面列举的各种功能。

  SDK 的思路：在应用层添加一个胖客户端，在这个客户端中实现各种功能。

  Service Mesh 的思路，体现在将 SDK 客户端的功能剥离出来，放到 Sidecar 中。就是把更多的事情下沉，下沉到基础设施中。

  从整体来看，应用是这样的：

  但在用户看来，应用长这样：

  

Service Mesh

  其中文译名是服务网格，这个词最早使用由开发Linkerd的Buoyant公司提出，并在内部使用。
  定义和基本构成

Istio

  Istio 是当前最受欢迎的 Service Mesh 框架，一句话定义 Istio：一个用来连接、管理和保护微服务的开放平台。它能给我们的微服务提供哪些功能呢？

连接

• 动态路由
• 超时重试
• 熔断
• 故障注入

保护

  安全问题一开始就要做好，在 Istio 实现安全通讯是非常方便的。Istio 支持双向 TLS 加密

控制

• 速率限制
• 黑白名单

观测

• 指标度量：每秒请求数，Prometheus 与 Grafana
• 分布式追踪：Jaeger 或 Zipkin
• 日志：非应用日志
• 网格可视化：快速理清服务的关系

  

---

---

  

何谓云原生？

  云原生是一种构建和运行应用程序的方法，是一套技术体系和方法论。云原生（CloudNative）是一个组合词，Cloud+Native。
  Cloud表示应用程序位于云中，而不是传统的数据中心；Native表示应用程序从设计之初即考虑到云的环境，原生为云而设计，在云上以最佳姿势运行，充分利用和发挥云平台的弹性+分布式优势。
  何为云原生？大概说一下最容易记住和理解的定义：DevOps+持续交付+微服务+容器。符合云原生架构的应用程序应该是：采用开源堆栈（K8S+Docker）进行容器化，基于微服务架构提高灵活性和可维护性，借助敏捷方法、DevOps支持持续迭代和运维自动化，利用云平台设施实现弹性伸缩、动态调度、优化资源利用率。

云元素的四要素

微服务：

  微服务架构的好处就是按function切了之后，服务解耦，内聚更强，变更更易；另一个划分服务的技巧据说是依据DDD来搞。

容器化：

  Docker是应用最为广泛的容器引擎，容器化为微服务提供实施保障，起到应用隔离作用，K8S是容器编排系统，用于容器管理，容器间的负载均衡。

DevOps：

  这是个组合词，Dev+Ops，就是开发和运维合体，实际上DevOps应该还包括测试，DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。

持续交付：

  持续交付是不误时开发，不停机更新，小步快跑，反传统瀑布式开发模型，这要求开发版本和稳定版本并存，其实需要很多流程和工具支撑。