018 云原生之基础架构

云原生应用对基础架构的基本要求有：

● 运行时间和隔离。

● 资源分配和调度。

● 环境隔离。

● 服务发现。

● 状态管理。

● 监测和日志记录。

● 度量聚合。

● 调试和追踪。

云应用程序肯定会依赖一个或多个服务来提供业务价值。提供一种让服务在每个环境的基础上找到彼此的方法是基础架构的责任。有些应用的服务发现需要调用 API 来实现，而有些应用则通过 DNS 或者网络代理透明地发现。具体的实现方式不重要，重要的是使用服务发现服务。

度量的指标一般称为服务级别指标（Service Level Indicator，SLI）或关键绩效指标（Key Performance Indicator，KPI）。这些指标是特定于应用程序的数据，让管理程序监测应用程序的性能在服务级别目标（Service Level Objectives，SLO）内。自动测量数据可以解决以下问题：

● 应用程序每分钟收到的请求数。

● 是否有任何错误。

● 应用程序延迟多久。

● 业务处理需要多长时间。

后端服务是指程序运行所需要的通过网络调用的各种服务，如数据库（MySQL、CouchDB），消息/队列系统（RabbitMQ、Beanstalkd），以及缓存系统（Memcached）。符合规则的应用程序应该可以在不进行任何代码改动的情况下，将本地数据库切换至异地或者云上的数据库服务。

符合十二要素的应用程序可以自我加载而不依赖于任何网络服务器。例如 Java 代码可以直接使用 JVM 的 Jetty，而不依赖于 Tomcat。这一点就像 Node.js 不需要 Apache 一样。

云原生基础架构由应用程序来维护，而云原生应用则由基础架构来维护，两者密不可分。这就要求基础架构和应用程序设计必须是简单的。如果一个应用程序比较复杂，则应该采用微服务模式，将复杂功能拆分为细微的服务，然后通过集成这些细微服务来组装成一个应用系统。但由微服务构成的如此复杂的系统，势必无法通过人工管理，应该采用自动化管理，这也是云原生应用的一个基本特征。

1. 当应用不再关注底层系统的情况时，就可以尝试云原生架构。

2. 如果采用云原生架构，将打破这种独立运作的组织架构，由传统纵向分割团队改为横向分割团队，每个小组可以自己负责纵向的所有事宜，从而更好地协作。

3. 如果采用云原生架构，将打破这种独立运作的组织架构，由传统纵向分割团队改为横向分割团队，每个小组可以自己负责纵向的所有事宜，从而更好地协作。

4. 适合云原生架构的应用必须职能单一、与系统无绑定，能够动态扩展实例数量。这就要求能够以无人值守的方式扩展应用实例，也要求状态持久化的存储服务独立于应用所在的服务器。

服务网格是用于处理服务到服务通信的专用基础设施层。它负责通过包含现代云原生应用程序的复杂服务拓扑来可靠地传递请求。实际上，服务网格通常实现为多个轻量级网络代理，这些代理与应用程序代码一起部署，但不需要知道应用程序。

Istio 的功能可以细分为以下四个类别：

● 流量管理：控制微服务之间的流量，以执行流量分割、故障恢复和金丝雀发布。

● 安全性：在微服务之间提供基于身份的强认证、授权和加密。

● 可观察性：收集度量值和日志，以更好地了解集群中运行的应用程序。

● 策略：强制实施访问控制、速率限制和配额，以保护应用程序。