不可变基础设施-Immutable Infrastructure

在这种模式中，任何基础设施的实例（包括服务器、容 器等各种软硬件）一旦创建之后便成为一种只读状态，不可对其进行任何更改。如果 需要修改或升级某些实例，唯一的方式就是创建一批新的实例以替换。

单体应用

• 开发效率变低
• 部署影响变大
• 可扩展性较差
• 技术选型成本高

  微服务

  每个微服务易于开发与维护，便于沟通与协作，很适合小团队敏捷开发与持续交付

微服务有持续交付的能力。

每个微服务职责单一，高内聚、低耦合。

微服务要单一职责，一个微服务尽量只做一件事。

每个微服务能够独立开发、独立运行、独立部署

• 每个微服务之间是独立的，如果某个服务部署或者宕机，只会影响到当前服务，而不会对整个业务系统产生影响

  每个微服务可以随着系统规模的不断扩大，面对海量用户和高并发，独立做水 平扩展与垂直扩展

k8s 可以快速新建实例。

微服务框架与服务网格

微服务框架

但微服务 框架如 HSF/Dubbo 或 Spring Cloud 以代码库的方式来封装这些能力。这些代码库 被构建在应用程序本身中，随着应用一起发布和维护，其实现方式和生命周期与业务逻辑耦合在一起的。微服务框架的升级会导致整个服务应用的重新构建和部署。所以 不同的微服务框架是不能相互结合的。

微服务框架不适用公有云

如果是在一家公司内部还可以通过行政命令强制公司内使用一样的技术栈、使用 一样的微服务框架进行编程。但如果提供的是云服务就不可能强制用户必须使用同一 个微服务框架。更何况很多语言其实是没有微服务框架的。即便是那些有微服务框架 的语言之间不同的微服务框架的设计也是完全不一样的。所以微服务框架在公有云面向大众提供服务的时候就显得很受限制。此时微服务框架代码级别内置集成的方式就 显得很累赘了，因此我们需要一个框架无关、语言无关甚至是协议无关的通用的微服 务解决方案。
为了解决上述挑战，社区提出了 Service Mesh（服务网格）架构。

服务网格

它 重新将服务治理能力下沉到基础设施，在服务的消费者和提供者两侧以独立进程的方 式部署。这样既达到了去中心化的目的，保障了系统的可伸缩性；也实现了服务治理 和业务逻辑的解耦，二者可以独立演进不相互干扰，提升了整体架构演进的灵活性； 同时服务网格架构减少了对业务逻辑的侵入性，降低了多语言支持的复杂性。
Istio 通过 Sidecar 的方式把微服务治理的能力下沉到业务进程之外，从而解除 了微服务治理和业务进程生命周期的强耦合关系。

knative

Knative 作为一个 Serverless 编排框架其 Autoscaler 的自动扩缩容能力可以 让应用在没有服务的时候缩容到零，完美的展示了无服务器的威力。Knative 是建立 在 Istio 之上的，基于 Istio 可以提供完整的 ServiceMesh 能力。可以看到 Knative 完美的结合无服务器和服务复杂度下沉这两个维度。