「Cloud Native Infrastructure」读书笔记

这是假期读的第二本书,以下是对本书的阅读的内容的一些总结:

就 Cloud native 这个词来说,已经被市场人员到处在用了,就跟 Microservice 一样,很难清晰地去定义到底什么是 Cloud native。在本书中,作者提到的 Cloud native 其实包含了两个部分的内容,一个是 Cloud native 的基础设施(Cloud native infrastructure),另一个是 Cloud native 的应用(Cloud native application)。作者对于 Cloud native infrastructure 的定义是:

Cloud native infrastructure is infrastructure that is hidden behind useful abstractions, controlled by APIs, managed by software, and has the purpose of running applications. Running infrastructure with these traits gives rise to a new pattern for managing that infrastructure in a scalable, efficient way.

所谓的 Cloud native 的基础设施就是当我们的基础设施(大量的 VM/Docker,复杂的网络,各种各样的储存等等)变的非常复杂和庞大的时候,通过人力是无法高效地进行运维的,在这样的大规模下,我们应该尽量地去避免人工介入,而是需要有一套软件来帮助我们更好地去管理我们的基础设施,可以让运行在这套基础设施上 Cloud native 的应用可以非常方便地被运维,部署,监控等等。那么怎么去设计管理 Cloud native 的基础设施的系统呢,作者提到了几个点,其中包括系统的自举,API 的设计等等,但是我觉得其中最重要的一点是 Reconciler Pattern,关于这个 Pattern,书中提到了四个原则:

  • Use a data structure for all inputs and outputs.
  • Ensure that the data structure is immutable.
  • Keep the resource map simple.
  • Make the actual state match the expected state.

其中最后一点和 Reconciler Pattern 的关系最大,这个也是 Kubernetes 中的方式,我们往 Kubernetes 中去提交一个 Spec,比如要求一个应用的实例的数量应该是 4,那么 Kubernetes 就会尽可能地去保证这个应用的实例的数量是 4,如果一个实例 Crash 了,它就马上新起一个实例。这就是所谓的 Reconciler Pattern,尽量让实际的状态可以和期望的状态匹配上。

Reconciler Pattern 在设计上非常大的一个优势就是它是声明式的,而不是反应式的。用户要做的是按照系统提供出的 API,直接告诉系统你想要什么,比如说,我想要一个应用的实例的数量保持在 4 个,系统就去考虑各种情况,让你的应用的数量保持在 4 个。而反应式的话,则是监听系统的事件,比如你的应用的某个实例 Crash 了,然后你监听到了这个事件之后,就调用系统的 API 去新创建一个实例。显然,对于用户来说,声明式的方式要简单地很多,不容易出错。而反应式则要求每一个应用都去监听系统的事件,不但侵入到了应用,也很容易出错。

在上面的 Reconciler Pattern 的四个原则中,第二点让数据结构是不可变的这一点也是非常重要的,但是我不是很明白这个点和 Reconciler Pattern 具体的关系在哪里?这个原则是说如果我们要修改一个数据结构,我们实际上不是修改它,而是新建一个新的,然后把原来的标记成过期,这样的好处是,我们可以保留数据结构中间的各种版本,当需要看下当前的 Infra 有哪些区别的,就可以把这些版本直接拿出来对比,非常方便地就可以回答线上环境到底发生了什么样的变更。

有了 Cloud native 的基础设施,我们还要有 Cloud native 的应用运行在上面,那么作为基础设施,我们还应该给应用到底提供什么样的能力呢,书中提到了八点:

  • Runtime and isolation(这里的 isolation 是指资源的 isolation,比如 CPU,Memory,Storage 等等)
  • Resource allocation and scheduling
  • Environment isolation(这里的 isolation 指的是环境的 isolation,比如 dev,test,staging,product)
  • Service discovery
  • State management(Readiness, Liveness)
  • Monitoring and logging
  • Metrics aggregation
  • Debugging and tracing

我们可以看到,上面的八个点中其实下面非常多的都是原来传统的中间件在干的一些事情,而在 Cloud native 的基础设施中,这些中间件正在往下沉,直接成为基础设施的一部分,为应用提供能力。而且在 CNCF 中,上面的八个点基本上都有一个对应的产品对应:

  • Runtime and isolation: containers, rkt
  • Resource allocation and scheduling: kubernetes
  • Environment isolation: kubernetes
  • Service discovery: kubernetes
  • State management: kubernetes
  • Monitoring and logging: Prometheus, Fluentd
  • Metrics aggregation: Prometheus
  • Debugging and tracing: OpenTracing, Jaeger

除了上面的八个点之外,我个人认为应该还加上一个点,就是 Network Resilient,这可以极大程度地解决应用之间的网络通信的问题,这个正是 Service Mesh 所提供的能力,在 CNCF 里面对应的产品是 Envoy(奇怪 istio 怎么还没有进入 CNCF)。

总结来说,本书的作者基本上把设计一个 Cloud native infrastructure 所需要做的事情都讲了一遍,包括上面没有提到的测试等等,大部分的内容其实就是 Kubernetes 目前已经做到的一些事情,如果你对 Kubernetes 的设计已经非常清楚了,那么这本书对你的价值可能不大,如果对 Kubernetes 的设计并不熟悉,那么相信你可以从这本书里面学到不少东西。

推荐阅读更多精彩内容

  • Spring Cloud为开发人员提供了快速构建分布式系统中一些常见模式的工具(例如配置管理,服务发现,断路器,智...
    卡卡罗2017阅读 121,143评论 16 134
  • Android 自定义View的各种姿势1 Activity的显示之ViewRootImpl详解 Activity...
    passiontim阅读 157,711评论 24 688
  • 心事入瑶琴, 无人会弦音。 孤标难自弃, 对影独沉吟。
    竹心梦话阅读 33评论 0 0
  • 周六的即兴舞蹈课上,老师和一位同学互动,结束后问我们他们之间后来进行不下去的问题在哪里,我们没看出来,他说因为那位...
    涵予张阅读 140评论 2 3
  • 上周出去听课,结果手机内存不够,还是请别人帮忙录的像。回来就想,我要买个手机u盘,这样相当于多了一个扩容的大内存呢...
    金明啊阅读 41评论 0 0