云原生架构选择原因

Posted 2023-04-08 程序小黑

云计算时传统软件架构的一场革命，云计算通过主机虚拟化实现了主机资源池化，并统一提供云化基础设施服务云托管服务。而随着应用上云的不断深入，企业需要去思考如何更好利用云的价值，在最大意义上发挥晕的价值，通过云原生技术来实现企业创新和数字化转型，这也是在云计算到达一个全新的层次需要进行的一个技术转变。

随着云计算技术的迅猛发展，云计算基本实现了普及，在传统计算方式中，OS为中间件直接提供服务，而应用是直接构建在中间件上的。设计师需要采购硬件、设计硬件、部署硬件、并根据需求的增长对硬件进行扩容、重新设置整个堆栈。

而通过云计算架构方案，能够实现业务的云上运行，实现Saas（软件即服务）、Paas（平台即服务）、laas（基础设施即服务）。
而传统的云计算采用虚拟机代替了原来的物理机，分布式计算成为了新的基础能力，但是这还没有完全发挥云的价值和能力，而且采用虚拟机的方式过于笨重，需要os的支持才能让应用进行运行，软件运维成本较高，需要针对环境进行进一步的开发和配置，这些问题都指向一个共同点——云的时代需要全新的技术架构来更好的利用云计算的优势，让业务更加敏捷，让成本更低的同时能够让系统能够弹性伸缩，更加灵活。这也是云原生架构需要解决的问题。

云原生技术发展路线：
2004-2007年Google 大规模使用容器技术Cgroups。
2008年Cgroups合并进入Linux内核。
2013年Docker项目发布。
2014年Kubernetes项目发布
2015年CNCF云原生基金会成立。Kubernetes成为第一个项目
2017年Kubernetes项目实施标准确立。
2018年云原生技术理念逐步萌芽形成。
而目前根据CNCF对于云原生的定义来说，云原生的代表技术就是容器、服务网格、微服务、不可变基础设施和声明式API。

云原生架构 - 另一种 API 范式 GraphQL

基于场景常见的微服务的API范式：REST、GraphQL、Webhooks和gRPC。

在诸多选择中，REST可能是最广为人知的，因为它在Web API中应用十分广泛。REST对于相当大范畴的API来说是一个非常好的标准。

但在一些需要API设计风格更细致入微的场景，还有其他的标准可供选择。比如我们今天要聊的GraphQL, GraphQL的一个巨大好处，是在默认情况下，它通常只发送最小请求，而REST通常发送完整请求（即默认同时发送它拥有的所有内容）。正因为如此，GraphQL在一些特定的用例中更加适用，在这些场景中，需要更明确的数据类型定义，并且倾向于使用较小的数据包来进行传输。

1. GraphQL 范式的特点

GraphQL 范式优点

• 所见即所得

• 减少网络请求次数

• 代码即文档

• 参数类型强校验

缺点：缓存，复杂性

适用场景：面向移动端的服务请求

RESTful 范式的缺陷

• 扩展性，单个RESTful接口返回数据越来越臃肿

• 多次请求，占用网络资源，响应慢

二、初识 GraphQL

GraphQL 的实现能让客户端获取以结构化的方式，从服务端结构化定义的数据中只获取想要的部分的能力。

符合 GraphQL 规范的实现我称之为 GraphQL 引擎。

这里的服务端不仅指网络服务，用 GraphQL 作为中间层数据引擎提供本地数据的获取也是可行的，GraphQL 规范并没有对数据源和获取方式加以限制。

操作模型：GraphQL 规范中对数据的操作做了定义，有三种，query（查询）、mutation（变更）、subscription（订阅）。

二、GraphQL 体验：Github V4 API

Explorer - GitHub Docs