揭开云的面纱,OpenAPI服务分析

入口分析

揭开云的面纱,从云的语言OpenAPI开始》
从语言角度切入介绍OpenAPI的特征。对应OpenAPI的另外一个入口就是ECS 控制台页面,从控制台页面可以友好地、点点鼠标完成云商品-ECS计算实例购买。而控制台页面最为精简、友好的页面,当之无愧的是“新人首次”进入的提示页面和相关流程。截图如下:
揭开云的面纱,OpenAPI服务分析

揭开云的面纱,OpenAPI服务分析

从上图不难发现有几个和商品相关的“显现”信息:
信息1: 产品规格
信息2: 操作系统
信息3: 网络带宽
信息4: 云盘大小
信息5: 产品规格族
信息6: 产品所在地域
信息7: 协议
信息8: 购买(或免费试用)

对比完整的非新用户,使用向导创建实例
一共有5个步骤,抽象下如下图所示
揭开云的面纱,OpenAPI服务分析

总结:

云算力商品ECS实例,其实还是依赖了很多“信息”的。这些信息的综合请求,构成一次下单购买的后端各种服务的“存在”。

链路抽象

云服务商品在线购买(无须物流运输),典型的web服务模式。那么web服务模式,就离不开典型[LAMP架构的基本要素](https://blog.51cto.com/xxrenzhe/1381844)。

早些时候简单的web应用完全可以follow 经典的LAMP模式搭建。如今,在微服务化架构普遍使用的背景下。典型的综合性页面的架构基本要素更加丰富。Microservices Architecture for Modern Digital Platforms
结合LAMP、微服务以及ECS购买入口信息,下面给出ECS的微服务一种示意图,用于表达:ECS购买页面背后的一些关键功能模块。注意这里省略了中间件的一些信息。本文重点在OpenAPI背后的“功能”分析。

揭开云的面纱,OpenAPI服务分析

部分功能的探讨

整个云服务后面一个庞大的体系,本文仅就作者个人观察或者接触思考的点做一个抛砖引玉。

服务链接协议

不难发现,服务链接协议有多层,服务协议链接内外部的系统。例如,用户与平台之间的协议。这里典型的就是OpenAPI透露的信息。如RunInstances
这一层协议典型的要求:功能向后兼容、功能原子性、功能可重入(也就是幂等性)、功能安全性、语言无关性(多语言的支持)等。

例如,平台内部组件之间的协议。从阿里云公开的资源[云原生架构白皮书](https://developer.aliyun.com/article/768699)不难发现,平台内部组件之间的协议典型如:
Apache Dubbo
Spring Cloud
Eclipse MicroProfile
Tars
SOFAStack
Dapr

微服务部分技术点的选择

技术点 优势 劣势
队列 为什么要使用队列?队列带来的优点:如可以做到对请求任务有序处理、优先级处理、高吞吐量(异步并行化处理) 需要持久化做到万无一失
事件驱动 为什么要使用事件驱动?事件驱动带来的优点:如可以接偶系统,对大型系统的高效演进、协作非常有帮助。准实时响应 事件的依赖关系处理
状态驱动 为什么要使用状态驱动?典型的面向服务的场景下,根据业务状态进行动作的执行。类似形式化语言 如编译原理的状态机工作原理 需要定义和掌握所有的状态和变化关系
轮询驱动 为什么要使用轮询驱动?持久化异步并行处理,可以实现最终一致性。如工作流 受任务量的突发性,可能导致部分任务等待时间过长
演进式驱动 为什么要使用演进式驱动?往往这组织、发展决定了系统很难一步设计到位,多半是随着业务发展而发展,带着这或那的问题演进 问题不到非解决不可的时候,很难停下来做重构、优化

这里带给我们的思考:
云这种长周期、在线服务的输出,要求服务向后兼容性(客户服务使用,不同于互联网的有些免费使用场景),同时支持业务发展。面临时间越久,积淀的包袱越多,在软件中的各种各样的“补丁”会严重拖累研发效能和功能的质量。

难点和挑战

并发
这是分布式系统天生面临的问题。总会在系统的某个地方需要采用锁服务,乐观锁或者悲观锁。在大型分布式系统中,在那个节点加锁、加什么锁,对整体性能影响还是满关键的。目前,业界需要一种自动检测、优化,系统的最佳加锁的位置和类型。

分布式一致性
CAP 在大型分布式系统中,不同的场景有不同的取舍。其中,通过存储一致性解决业务一致性是非常好的解决方案。例如:任务从A到B到C,可以依赖数据存储的状态变化来管理页面状态的变化,实现分布式一致性。例如:分布式抢锁服务,依赖分布式锁服务实现:分布式存储一致性。

确定性
确定性这里一方面是:请求身份的唯一性、合法性保障,另外一方面是重复请求的幂等性。
在遇到异常的情况下,资源或者数据的回滚、清理非常重要。越是成熟的系统,越害怕异常的出现。因为成熟系统中的异常,排查更加复杂,成本更大。

稳定性
毫无疑问稳定性从没过时,并且只要系统发生变更,稳定性就可能面临威胁。可能目前最好的防范就是:不停地人为制造一些问题,时不时做演练,锤炼系统的稳定性。

总结

本文从ECS实例购买入口分析起,给出后端功能的抽象分析和拆解,并对支撑这种拆解的微服务部分技术点做分析。整体上可以帮助大家对ECS OpenAPI、背后功能实现有一个概括性的认识。

上一篇:office 2003安装:错误1303 解决方法


下一篇:为什么说云计算技术值得你投简历