SOA 、MSA与CNA比较

SOA代表面向服务的架构，MSA是微服务架构简称，CNA是云原生架构简称。
SOA肯定是会向后两者转变，但是MSA是不是一定转向CNA，还是可能直接转向Serverless并没有定论，该文虽然默认CNA比MSA高级，但是作者不是上帝，我们看看该文的闪光点:

端点和管道
在从SOA转向MSA过程中，服务之间通讯方式转变为“智能端点和哑管道” ，微服务端点是智能的，通讯管道应该是简单非智能的，微服务之间通讯不依赖于集中式智能路由层，而是依赖于拥有某些平台级功能的智能端点，比如spring cloud提供的Zuul动态路由和嵌入各个服务的Ribbon负载平衡以及Hystrix断路器，这些负责网络通讯的功能被分配到各个微服务的编码和配置中。

在进入CNA的后Kubernetes时代，智能端点和哑管道再次被颠覆，哑管道已经完全被服务网格技术所取代。而且，服务网格甚至比传统的ESB更智能。网格可以执行动态路由，服务发现，基于延迟的负载平衡，响应类型，指标和分布式跟踪，重试，超时。

ESB只有一个集中路由层，而服务网格每个微服务通常都有自己的路由器: 边车代理。更重要的是，这个新管道（平台和服务网格）不像ESB，它并没有任何业务逻辑; 他们完全专注于基础架构问题，使服务专注于业务逻辑。

Kubernetes平台（包含所有其他技术）还负责资源管理，调度，部署，配置管理，扩展，服务交互等。因此，其实已经变成智能端点代理和智能管道。

对微服务的强制要求
由于服务网络可以检测故障，会不断重启你的微服务，也就是你的微服务可能会不断被重启。这就对微服务功能有强制要求，必须幂等。

为了适合云原生环境中的自动化，服务必须是：

幂等重启（服务可以被杀死并多次启动）。

幂等扩展/缩小（服务可以自动扩展到多个实例）。

幂等服务生产者（其他服务可能会重试被调用）。

幂等服务使用者（服务网格可以重重试调用）。

如果你的服务执行上述操作一次或多次时服务的行为始终相同，那么平台将能够在没有人为干预的情况下从故障中恢复你的服务。

分布式系统中的应用程序安全性和正确性也就是事务机制仍然是应用程序自己的责任。

原文

[该贴被banq于2018-09-30 15:12修改过]