分布式系统开发实战：CloudNative架构，CloudNative优点面临挑战

Cloud Native与微服务架构的关系

Cloud Native与微服务存在某种意义上的联系，可以说微服务的盛行加快了Cloud Native的实践，而Cloud Native的实践反过来又提供了利于微服务架构实施的基础设施。

微服务的部署具有以下特点。

·首先每个微服务实例都是整个分布式系统的组成部分，这个部分是不可分割的、最小的自治单元。为了便于部署和运维微服务，推荐采用每台主机部署一个单独的微服务实例的方式，而这种方式往往需要占用较多的主机数量。

·为了系统的可扩展性，微服务实例可以被设计为可以扩展或者减少，以适应业务的变化。

Cloud Native环境以云为优先，可以自己搭建私有云，也可以租用运营商提供的公有云服务，但不管怎么样，按需使用云服务，都可以最大化节省部署微服务所带来的成本。所以，从这个意义上讲，CloudNative促进了微服务架构的流行。

 Cloud Native与Serverless架构的关系

Serverless架构依赖第三方服务（“云端”）来实现对逻辑和状态进行管理的应用。因此，Cloud Native环境以云为优先，自然成了为Serverless架构提供服务支持的土壤。

Cloud Native的优点及面临的挑战

最早提出Cloud Native概念的是Pivotal公司的Matt Stine。在他的Migrating to Cloud-Native Application Architectures书中，详细解释了Cloud Native产生的背景。Cloud Native这个概念是多种不同思想的一个集合，这些思想与许多公司正在转移到云平台的趋势是一致的。这些思想包括DevOps、持续交付、微服务、敏捷基础设施、康威定律，以及根据商业能力对公司进行重组。Cloud Native既包含技术（比如微服务、敏捷基础设施等），也包含管理（比如DevOps、持续交付、康威定律、重组等）。Cloud Native也可以说是一系列Cloud技术、企业管理方法的集合。

Cloud Native优点

总结一下，Cloud Native具有以下优点。

1.降低成本

毫无疑问，实施Cloud Native可以帮助企业降低成本，无论是使用云基础架构设施，还是使用PaaS或者SaaS，企业都能够按需使用云服务，按需缴费。无论是个人应用，还是超大规模的集群部署，都可以帮助他们减少运营成本，从而增加利润。

另外一个成本来自运维。实施了Cloud Native的企业，可以将运维成本转嫁给云供应商，从而避免了企业自己招聘专业人员来维护，有效降低了人力成本。

2.提升速度

无论是个人开发者，还是公司，Cloud Native可以把一个新产品或者服务更快速地推向市场。一个初创公司或者一个企业想要更快速地发展，它们实施Cloud Native架构是为了更快速地创新。那么Cloud Native是如何做到提升速度的？

云服务供应商往往提供比较成熟而且全面的云服务解决方案，可以帮助企业快速接入它们的服务。这些服务包括了从基础架构到中间件，再到云存储、云缓存、云计算等各个方面，企业可以开箱即用地采用这些服务，省去了自研这些服务所花费的时间。

同时，由于云服务都是按需使用、按需购买的，企业可以用比较少的成本去“试错”。这样，企业更加愿意去尝试一些新的技术方案，从而缩短了项目前期的技术调研和准备，加快了推出产品的速度。

Cloud Native推崇持续集成、持续交付的理念，这会帮助企业构建自动发布的流水线，从而加快了从编码到测试再到发布的进程。

3.可扩展

具备自动扩展的云服务，可以帮助企业应用实现自动扩展。

在流量高峰，运维机制监测到预警阈值，会自动扩展服务实例。类似地，在流量的低谷，运维机制也能监测到预警阈值，会自动减少服务实例。这样，企业无须担心市场扩展的速度。

举例来说，在“双11”期间，各大电商都会迎来流量的高峰，那么这个时候可以多预备服务实例，以应对并发访问的压力。当淡季来临，将多余的服务实例关闭，从而减少运营的成本。而这一切对于客户来说都是无感知的。

4.减少风险

以前，传统的运维需要有专门的人员全天候轮流值守，生产环境一旦出现问题，马上需要人员去处理。因为，风险不可控，不知道什么时候来临。而今，使用Cloud Native省去了很多人工运维的工作。自动化运维系统承担了几乎所有的监测的工作，并且能够胜任处理大部分异常问题。比如，上面提到的突如其来的流量高峰，系统能够自动监测到这类异常，并通过自动扩展服务实例的方式来应对这些问题。

当然，系统并不能代替人的所有工作。但在系统遇到无法处理问题的时候，系统也可以通过邮件、短信等方式来通知运维人员，从而使运维人员可以异步处理这些问题，而不用时刻守候在监控器前。

 Cloud Native不是“银弹”

任何技术都不是“银弹”，Cloud Native同样如此。虽然理论上，所有的技术都可以上云，但也要区分场景。

比如，我想要做一个手机版本的记事本软件或者单机版本的计算器。这类应用的特征都是纯粹的客户端程序，无须连接服务器，没有后台，自然也就没有必要采用Cloud Native。

当然，可以换一个场景，比如，我希望这个记事本软件，无论是在手机端还是在PC端，都能做到数据的同步，那么这个时候就需要有一个服务端程序来做数据同步以及数据的存储，此时，采用Cloud Native架构就是一个非常不错的选择。Cloud Native可以降低部署服务端程序的成本。

面临的挑战

使用Cloud Native架构对于企业来说是一场革命。这场革命所带来的影响，并不全是技术上的，同时也包括了管理上的。

从技术上来说，Cloud Native所影响的技术有微服务、敏捷基础设施、容器技术、持续集成工具等多方面的话题。·使用IaaS：运行的服务器可以灵活地按需分配。

·使用或演变为微服务架构设计系统：每个组件都很小并且互相解耦。

·自动化和编码：取代人工执行脚本和代码。

·容器化：把应用进行封装处理，使它们测试和部署时更加容易。

·编排：使用现成的管理和编排工具抽象化生产环境中的服务器个体。

从管理上来说，Cloud Native需要团队拥有敏捷开发、DevOps、持续交付、康威定律等方面的思想。

·敏捷开发：面向问题的解放方式。

·DevOps：打造全职能的项目团队。

·持续交付：构建了从编码、测试、部署、发布的自动化交付流水线。

·康威定律：组织沟通方式决定系统设计。

不管怎么样，越早面对这些挑战，越早将企业架构转变为CloudNative，越能在当今的软件市场占有一席之地。

本篇小结

本篇介绍了Cloud Native架构的概念、特征及成功案例，也对比了Cloud Native架构与微服务架构、Serverless架构的区别和联系。同时我们也要认识到Cloud Native架构不是“银弹”，仍然需要面临非常多的挑战。