通过本篇文章您可以了解到以下内容:
- 云原生（Cloud Native）历史简介与定义
- 关于微服务架构设计的思考
云原生（Cloud Native）历史简介与定义
云原生（Cloud Native）这个词相信大家再熟悉不过了，谈到这个词不得不先从一家公司说起，那就是Pivotal（目前已经回归到了VMware）。让我们把时间倒回到2013年，回过头来看一看云原生的发展历史。
![]()
2013 年 Pivotal 的 Matt Stine 首次提出了云原生（ Cloud Native ）的概念。
2015 年 Pivotal 的 Matt Stine 在他的《Migrating to Cloud Native Application Architectures - 迁移到云原生应用架构》书中对云原生应用架构进行了深入的讨论。
此书开篇从四大方面谈到了为什么要构建云原生应用架构:
![]()
（速度、安全、弹性扩展能力、移动应用和客户端的多样性）
此外在说明了为什么构建云原生应用架构的原因之后，进一步讨论了如何定义云原生应用架构:
![]()
（符合 12 因素应用、面向微服务架构、自服务敏捷架构、基于 API 的协作、抗脆弱性）
在此五大要素中的《符合 12 因素应用》一项又包括如下内容：
Codebase、Dependencies、Config、Backing services、Build, release, run、Processes、Port binding、Concurrency、Disposability、Dev/prod parity、Logs、Admin processes
2015 年 Google 作为发起者成立了云原生计算基金会（ CNCF ），随着云计算不断的发展，云原生的定义也不断的进行完善，到目前为止，让我们来看下 CNCF 对于云原生的定义（部分截取）
Cloud native technologies empower organizations to build and run scalable applications in modern, dynamic environments such as public, private, and hybrid clouds. Containers, service meshes, microservices, immutable infrastructure, and declarative APIs exemplify this approach.
These techniques enable loosely coupled systems that are resilient, manageable, and observable. Combined with robust automation, they allow engineers to make high-impact changes frequently and predictably with minimal toil.
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。
这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。
2017 年 Matt Stine 对云原生架构进行了进一步说明，总体来说概括为六个方面:
![]()
（模块化、可观测性、可部署性、可测试性、可处理性、可替代性）
2019 年 Pivotal 回归到了 VMware，关于云原生的定义又给出了进一步的说明，同时也包括云原生架构的原则。
详细信息可参见 VMware 官网
以上就是关于云原生（Cloud Native）的历史简介。通过上面的介绍不难看出，无论是 Pivotal（VMware）最早提出的关于云原生的五个关键词（符合 12 因素应用、面向微服务架构、自服务敏捷架构、基于 API 的协作、抗脆弱性）还是 CNCF 对云原生的定义，都包含了一个词，那就是微服务架构。
![]()
关于微服务架构设计的思考
微服务这个词相信大家早已经耳熟能详，谈到微服务架构就不得不先说到另外一个词语它就是 Monolithic architecture （一体化架构）。
Monolithic architecture 是软件程序的传统模型，它被构建为一个独立于其他应用程序的统一单元。它具有一个将所有业务关注点耦合在一起的代码库。接下来让我们来看看这种技术架构的优势：
![]()
- 易于部署（一个可执行的文件或者目录使得部署更加容易）。
- 简化部分测试（由于Monolithic architecture是集中的单元，因此像End-To-End这种类型的测试相比分布式系统来说会更加快速，方便）。
- 易于调试（所有的代码位于同一个项目工程内部，很容易跟踪请求流程并找到问题所在）。
- 应用早期阶段成本较低（所有的代码位于同一个项目工程内部，打包在一个部署单元中，基础设施成本和开发成本都没有而外的费用）。
正是由于上述的优势，Monolithic architecture 通常会用于项目开发的早期阶段。但是随着时间的推移，业务功能需求不断的增加，项目工程逐渐变大，一些弊端也逐步显现出来:
![]()
- 缓慢的开发速度（随着业务功能不断的增加，单体应用的规模也会越来越大，随之而来的是使得开发越来越复杂和缓慢）
- 比较弱的扩展性（因为所有代码位于同一工程内部，无法针对特定的业务功能模块进行独立扩展，除非将整个应用再次重新部署）
- 基础设施的成本增加（在出现性能问题的情况下，您需要扩展整个服务，而不是具体某一功能，这样会带来额外的成本开销）
- 测试变得越来越困难（即使是微小的改动，也要对整个工程进行回归测试）
- 可靠性降低（如果任何模块出现不可预见的错误， 都可能会影响整个应用程序）
- 在采用新技术方面存在障碍（由于框架和语言的改变可能对整个应用程序产生影响，因此这种改变无论是在时间成本还是经济成本上都是非常昂贵的）
面对上面描述的问题，有一个想法应运而生，那就是我们是否可以将这种 Monolithic architecture 根据业务属性拆分成若干个互相连接的服务而不是构建单一的应用程序。这些服务有着自己的业务逻辑（对应独立的代码库）和数据。这些服务公开 REST、RPC 或者是基于 Message 的 API 用于互相通信。从而通过这种转变来解决上述所说的弊端。
答案是肯定的，同时也可以理解为是一种技术架构的演进，即从 Monolithic architecture到 Microservices architecture 。
![]()
这时候微服务架构终于登场了, 但是此时相信大家也会有以下一些疑问：
- 微服务架构的由来、历史是怎样的?
- 微服务架构带来的好处到底有哪些?
- 以及相比传统巨石应用的优势又有哪些?
- 怎样把巨石应用进行拆分并构建微服务架构?
- 以及这个拆分的原则又是什么?
在下期的文章中会继续和大家进行交流分享，敬请期待! 如您有任何建议，欢迎随时联系我们！
参考链接：
![]()
作者简介
李刚，VMware 大中华区应用现代化部门高级系统架构师，资深企业级软件开发和软件系统架构师。Spring Cloud开源社区项目贡献者、Netflix开源社区贡献者。近几年，参与并主导了许多大型企业客户的应用现代化数字转型项目，涉及物流、制造、金融等诸多领域。特别对微服务实现方法、现代化应用架构设计、云原生实施落地、开源软件技术等方面有着丰富经验。
来源｜公众号：VMwareTanzu云原生
