Managing Cloud Native Applications

云原生應用程序旨在由基礎設施維護。就像我們在前面的章節中所示，云原生基礎設施旨在由應用程序維護。

Cloud native applications are designed to be maintained by infrastructure. As we’ve shown in the previous chapters, cloud native infrastructure is designed to be maintained by applications.

使用傳統基礎架構，安排，維護和升級應用程序的大部分工作都是由人工完成的。這可以包括在單個主機上手動運行服務，或者在自動化工具中定義基礎設施和應用程序的快照。

With traditional infrastructure, the majority of the work to schedule, maintain, and upgrade applications is done by humans. This can include manually running services on individual hosts or defining a snapshot of infrastructure and applications in automation tools.

但是，如果基礎設施可以由應用程序管理，并同時管理應用程序，那么基礎架構工具就變成了另一個應用程序。工程師對基礎設施的職責可以在協調器模式中表示，并內嵌到在該基礎結設施上運行的應用程序中。

But if infrastructure can be managed by applications and at the same time manage the applications, then infrastructure tooling becomes just another application. The responsibilities engineers have with infrastructure can be expressed in the reconciler pattern and built into applications that run on that infrastructure.

我們在過去的三章中解釋了如何構建可以管理基礎設施構的應用程序。本章將介紹如何在基礎設施上運行這些應用程序或任何應用程序。

We just spent the past three chapters explaining how we build applications that can manage infrastructure. This chapter will address how to run those applications, or any application, on the infrastructure.

如前所述，保持基礎設施和應用程序簡單非常重要。管理應用程序復雜性的一種常用方法是將它們分解為方便理解的小組件。我們通常通過創建單一用途服務來實現這一目標，或將代碼分解為一系列事件觸發函數。

As discussed earlier, it’s important to keep your infrastructure and applications simple. A common way to manage complexity in applications is to break them apart into small, understandable components. We usually accomplish this by creating single-purpose services, or breaking out code into a series of event-triggered functions.

即使是最自動化的基礎設施，小的，可部署單元的不斷激增也可能是壓倒性的。管理大量應用程序的唯一方法是讓它們采用第1章中描述的功能操作。應用程序需要在可以大規模管理之前成為云原生的。

The proliferation of smaller, deployable units can be overwhelming for even the most automated infrastructure. The only way to manage a large number of applications is to have them take on the operational functionally described in Chapter 1. The applications need to become cloud native before they can be managed at scale.

本章不會幫助您構建下一個優秀的應用程序，但它應該為您提供一些起點，使您的應用程序在云原生基礎設施上運行時運行良好。

This chapter will not help you build the next great app, but it should give you some starting points in making your applications work well when running on cloud native infrastructure.

Application Design

有很多書討論了如何做應用程序的架構。本書不打算成為其中之一。但是需要了解的是，應用程序架構如何影響有效的基礎設施設計。

There are many books that discuss how applications should be architected. This book is not intended to be one of them. However, it is still important to understand how application architecture influences effective infrastructure designs.

正如我們在第1章中討論的那樣，我們將假設應用程序設計為云原生的，因為它們從云原生基礎設施中獲得了最大的好處。從根本上說，云原生意味著應用程序設計為由軟件管理，而不是由人類管理。

As we discussed in Chapter 1, we are going to assume the applications are designed to be cloud native because they gain the most benefits from cloud native infrastructure. Fundamentally, cloud native means the applications are designed to be managed by software, not humans.

打包方式的設計是一個單獨思考的問題，并不是云原生應用的關鍵因素。應用程序可以是云原生的，并打包為RPM或DEB文件，并部署到VM而不是容器。它們可以是用Java或Go編寫的單體應用或微服務。

The design of an application is a separate consideration from how it is packaged. Applications can be cloud native and packaged as an RPM or DEB files and deployed to VMs instead of containers. They can be monolithic or microservices, written in Java or Go.

這些實現細節不是為應用在云中運行而設計的。

These implementation details do not make an application designed to run in the cloud.

舉個例子，讓我們假設我們有一個用Go編寫的應用程序并打包在一個容器中。我們甚至可以說容器在Kubernetes上運行，并且無論你選擇什么定義，它都會被認為是微服務。

As an example, let’s pretend we have an application written in Go and packaged in a container. We can even say the container runs on Kubernetes and would be considered a microservice by whatever definition you choose.

這個假想的應用程序是云原生的嗎？

Is this pretend application “cloud native”?

如果應用程序將所有活動記錄到文件并對數據庫IP地址進行硬編碼，該怎么辦？也許它不接受運行時動態配置并在本地磁盤上存儲狀態。如果它不以可預測的方式退出，或掛起并等待人類調試它會怎么樣？

What if the application logs all activity to a file and hardcodes the database IP address? Maybe it doesn’t accept runtime configuration and stores state on the local disk. What if it doesn’t exit in a predictable manner, or hangs and waits for a human to debug it?

這個假想的應用程序可能會從所選語言和打包中看起來是云原生的，但絕對不是。像Kubernetes這樣的框架可以通過各種功能幫助管理這個應用程序，但即使你能夠運行它，該應用程序顯然也是為了由人類維護和運行而設計的。

This pretend application may appear cloud native from the chosen language and packaging, but it is most definitely not. A framework such as Kubernetes can help manage this application through various features, but even if you’re able to make it run, the application is clearly designed to be maintained and run by humans.

在第1章中更詳細地解釋了使應用程序在云本機基礎架構上運行得更好的一些功能。如果我們具有第1章中規定的功能，那么應用程序還有另一個考慮因素：我們如何有效地管理它們？

Some of the features that make an application run better on cloud native infrastructure are explained in more detail in Chapter 1. If we have the features prescribed in Chapter 1, there is still another consideration for applications: how do we effectively manage them?

Implementing Cloud Native Patterns

彈性，服務發現，配置中心，日志記錄，健康檢查和指標等模式都可以通過不同方式在應用程序中實現。實現這些模式的常見做法是通過導入應用程序的標準語言庫。 比較好的例子像java的庫，Netflix OSS和Twitter Finagle。

Patterns such as resiliency, service discovery, configuration, logging, health checks, and metrics can all be implemented in applications in different ways. A common practice to implement these patterns is through standard language libraries imported into the applications. Netflix OSS and Twitter’s Finagle are very good examples of implementing these features in Java language libraries.

當您使用庫時，應用程序可以導入這些庫，它將自動獲得許多這些功能而無需額外的代碼。當group內支持的語言很少時，此模型很有意義。這些庫讓最佳實踐成為容易的事情。

When you use a library, an application can import the library, and it will automatically get many of these features without extra code. This model makes a lot of sense when there are few supported languages within an organization. It allows best practice to be the easy thing to do.

當group開始實施微服務時，他們傾向于轉向多語言服務.這樣可以自由地為服務選擇正確的語言，但卻很難為所有語言維護庫。

When organizations start implementing microservices, they tend to drift toward polyglot services. This allows for freedom to choose the right language for the ser‐ vice, but makes it very difficult to maintain libraries for all the languages.

獲得這些功能的另一種方法是通過所謂的“邊車模式”。此模式將進程與實現各種管理功能的應用程序捆綁在一起。它通常作為一個單獨的容器實現，但您也可以通過在VM上運行另一個守護程序來實現它。舉個例子，“邊車”應該考慮以下內容：

Another way to get some of these features is through what is known as the “sidecar” pattern. This pattern bundles processes with applications that implement the various management features. It is often implemented as a separate container, but you can also implement it by just running another daemon on a VM.Examples of sidecars include the following:

Envoy proxy：為服務添加彈性和指標數據

Registrator：使用外部服務進行服務注冊

Configuration：監視配置更改，并通知服務進程重新加載

Health endpoint：提供HTTP端點以檢查應用程序的運行狀況

Envoy proxy：Adds resiliency and metrics to services
Registrator：Registers services with an external service discovery
Configuration：Watches for configuration changes, and notifies the service process to reload
Health endpoint：Provide HTTP endpoints for checking the health of the application

Sidecar容器甚至可用于適配多語言容器以暴露特定于語言的endpoint，來讓服務于使用標準庫的應用程序進行交互。 Netflix的Prana就是為不使用標準Java庫的應用程序設計的

Sidecar containers can even be used to adapt polyglot containers to expose language-specific endpoints to interact with applications that use libraries. Prana from Netflix does just that for applications that don’t use their standard Java library.

當有特定團隊管理邊車時，邊車模式是有意義的。如果工程師想要在他們的服務中暴露指標，他們可以將其構建到應用程序中——或者使用單獨的團隊管理的邊車，來處理日志記錄輸出并為其暴露計算指標。

Sidecar patterns make sense when centralized teams manage specific sidecar processes. If an engineer wants to expose metrics in their service, they can build it into the application—or a separate team can also provide a sidecar that processes logging output and exposes the calculated metrics for them.

在這兩種情況下，服務都可以添加功能，而不是重寫應用程序。一旦能夠使用軟件管理應用程序，我們就來看看應該如何管理應用程序的生命周期。

In both cases, the service can have functionality added with less effort than rewriting the application. Once the ability to manage the application with software is available, let’s look at how the application’s life cycle should be managed

轉載于:https://www.cnblogs.com/langshiquan/p/10960665.html

總結

以上是生活随笔為你收集整理的《Cloud Native Infrastructure》CHAPTER 7 （1）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。