文章目录
前言
云计算 | 青训营笔记
上一篇笔记讲了云计算的几个方面，这一篇来讲讲与云计算相关的概念:云原生。
一、什么是云原生？
首先，云原生借了云计算的东风，没有云计算，自然没有云原生，云计算是云原生的基础。
随着虚拟化技术的成熟和分布式框架的普及，在容器技术、可持续交付、编排系统等开源社区的推动下，以及微服务等开发理念的带动下，应用上云已经是不可逆转的趋势。
云计算的3层划分，即基础设施即服务(IaaS)、平台即服务(PaaS)、软件即服务(SaaS)为云原生提供了技术基础和方向指引，真正的云化不仅仅是基础设施和平台的变化，应用也需要做出改变，摈弃传统的土方法，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点，重新设计，从而建设全新的云化的应用，即云原生应用。
Pivotal公司的Matt Stine于2013年首次提出云原生（CloudNative）的概念；2015年，云原生刚推广时，Matt Stine在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：因素、微服务、自敏捷架构、基于API协作、扛脆弱性；到了2017年，Matt Stine在接受InfoQ采访时又改了口风，将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理6特质；而Pivotal最新官网对云原生概括为4个要点：DevOps+持续交付+微服务+容器。
二、云原生-容器化技术
2.1、 什么是容器？
容器是云原生概念的重要组成部分，一种计算单元，容器比虚拟化技术更轻量化、更小开销的方式运行，作为应用的包装形式，容器赋予应用独立和便携的能力。随着Docker、Kubernetes技术的成熟，容器也成为了时下最火的开发理念。并非所有的应用都适合选择容器，开发者可以根据自己应用的特点和需求选择最适合的计算单元。如果应用是高性能、互信的，且处于同一个管理区域，那么用线程或者进程就可以满足；但如果你的应用是多租户的，并且和其他应用运行在同一个空间，那么你就需要考虑如何将这些应用安全地隔离开，使得数据不会被泄露或性能受到影响，容器也许就是一个不错的选择。
容器是「高度隔离的进程」：在一般进程的隔离基础上增加了新的隔离机制，这些隔离机制是使用Linux的内核提供的，它包括一些命名空间**（Name Spaces）和CGroup**。命名空间可以分为网络、存储和计算三大类。其中，最为重要的是网络命名空间。它保证了容器的网络是独立于其他容器网络的。每个容器自己看到的文件系统和其他容器的是不共享的，每个容器只能看到自己的进程ID，而进程编号也是连续的。容器最大的特征没有自己独立的操作系统，而是共享其宿主机上的一个操作系统；而虚拟机则运行在「一台独立的服务器上」，容器相比于虚拟机的成本小但隔离性欠缺。
命名空间中提到有网络、存储、计算三者区别。这里主要讲解下存储、计算两者的应用：
2.2、弹性计算资源类型：
- 服务资源调度：对于服务资源调度来说，主要区别有微服务与大服务提供弹性计算资源。
- 计算资源调度： 对于计算资源调度可以分为在线计算资源调度、与离线资源调度。在线的例子：热销的榜单更新，你时常盯着什么产品是热销的。离线的例子：离线的榜单更新，就算你没有盯着热销榜单，但是他还是需要更新。
- 消息队列：一部分的弹性资源需要提供给消息队列，在线时消息队列主要进行：削峰、异步、解耦的作用。离线时：主要是进行大数据分析如Kafka等。
三、云原生-DevOps
3.1、 DevOps是什么？
DevOps 是 Development（开发）和 Operations（运维)的组合，是一种方法论，是一组过程、方法与系统的统称，实际上DevOps应该还包括测试，DevOps是一个敏捷思维，是一个沟通文化，也是组织形式，为云原生提供持续交付能力。
3.2、 CI/CD与DevOps的联系
提到DevOps那就离不开CI/CD。
- CI: CI 的英文名称是 Continuous Integration，中文翻译为持续集成；CI 中，开发人员将会频繁地向主干提交代码，这些新提交的代码在最终合并到主干前，需要经过编译和自动化测试流进行验证；
- CD:对于CD则包括了持续交付（ Continuous Delivery） 和持续部署 （Continuous Deployment）。持续交付意味着所有的变更都可以被部署到生产环境中，持续部署意味着所有的变更都会被自动部署到生产环境中，但是出于业务考虑可以选择不部署；如果要实施持续部署，必须先实施持续交付；
CI/CD与DevOps之间的联系：
DevOps 是 CI、CD 思想的延伸，CI、CD 是 DevOps 的基础核心，如果没有 CI、CD 自动化的工具和流程，我们谈 DevOps 便没有意义。
而对于真正生产流程图可以归结如以下：
四、云原生-微服务
4.1、什么是微服务？
微服务是指将大型复杂软件应用拆分成多个简单应用，每个简单应用描述着一个小业务，系统中的各个简单应用可被独立部署。微服务具有降低系统复杂度、独立部署、独立扩展和跨语言编程等优点。但微服务架构的灵活、开发的快捷也带来了运维的挑战和分布式系统的复杂性。
4.2、 微服务常用组件
- 服务注册：服务提供方将自己调用地址注册到服务注册中心，让服务调用方能够方便地找到自己。
- 服务发现：服务调用方从服务注册中心找到自己需要调用的服务的地址。
- 负载均衡：服务提供方一般以多实例的形式提供服务，负载均衡功能能够让服务调用方连接到合适的服务节点。并且，节点选择的工作对服务调用方来说是透明的。
- 服务网关：服务网关是服务调用的唯一入口，可以在这个组件是实现用户鉴权、动态路由、灰度发布、A/B 测试、负载限流等功能。
- 配置中心：将本地化的配置信息（properties, xml, yaml 等）注册到配置中心，实现程序包在开发、测试、生产环境的无差别性，方便程序包的迁移。
- API 管理：以方便的形式编写及更新 API 文档，并以方便的形式供调用者查看和测试。
- 集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将所有微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户能够在统一的界面中使用系统。
- 分布式事务：对于重要的业务，需要通过分布式事务技术（TCC、高可用消息服务、最大努力通知）保证数据的一致性。
- 调用链：记录完成一个业务逻辑时调用到的微服务，并将这种串行或并行的调用关系展示出来。在系统出错时，可以方便地找到出错点。
- 支撑平台：系统微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，那么，就需要将大部分的工作自动化。现在，可以通过 Docker 等工具来中和这些微服务架构带来的弊端。 例如持续集成、蓝绿发布、健康检查、性能健康等等。
4.3、微服务的优势
- 易于开发和维护：一个微服务只会关注一个特定的业务功能，所以业务清晰、代码量较少。开发和维护单个微服务相对简单。
- 单个微服务启动较快。
- 局部修改容易部署：单体应用只要有修改，就得重新部署整个应用。微服务解决了这样的问题。一般来说，对某个微服务进行修改，只需要重新部署这个服务即可。
- 技术栈不受限制：在微服务架构中，可以结合项目业务及团队的特点，合理的选择技术栈。
- 按需伸缩：可根据需求，实现细粒度的扩展。
4.4、微服务的劣势
- 运维要求高：更多的服务意味着要投入更多的运维。
- 分布式带来的复杂性：使用微服务构建的是分布式系统。对于一个分布式系统，系统容错、网络延迟、分布式事务等都会带来巨大的问题。
- 接口调整成本高：微服务之间通过接口进行通信。如果修改某一个微服务的API，可能所有用到这个接口的微- 服务都需要进行调整。
4.5、架构图
对于go项目的微服务架构图，可以给出如下架构图（仅供参考，不同项目，微服务的架构也不同，根据实际业务场景来定）。
五、云原生- 服务网格
5.1、什么是服务网格（Service Mesh)？
Service Mesh即为“服务网格”，是用于处理服务与服务之间通信的基础设施层，主要负责为复杂构建的云原生应用提供一个可靠网络传递请求。如果简单的描述的话，可以将它比作是应用程序或者说微服务间的 TCP/IP，负责服务之间的网络调用、限流、熔断和监控，同样使用 ServiceMesh 也就无须关系服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如 Spring Cloud架构，现在只要交给 Service Mesh 。
5.2、服务网格架构图
对于服务网格这个概念的架构图：
对于实际项目所拥有的架构图（仅供参考）：
