入口分析

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

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

对比完整的非新用户，使用向导创建实例
一共有5个步骤，抽象下如下图所示

总结：

云算力商品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透露的信息。如RunInstances
这一层协议典型的要求：功能向后兼容、功能原子性、功能可重入（也就是幂等性）、功能安全性、语言无关性（多语言的支持）等。

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

微服务部分技术点的选择

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

难点和挑战

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

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

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

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

总结

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