1.0阶段就是从零到一的过程,最开始的架构就是物理机型对应部署规格,但是第三方就要给终端用户提供硬件隔离,所以基于容器架构,当时也是我们自研的容器平台,我们当时会有各种各样的物理机型,但是都有不一样的Disk,为了让每个机器尽量脱离我们可能就会考虑这个机器上部署多少A端应用和多少B端应用,所以我们都会有这种部署规格对应。
可以清晰地看到1.0架构的痛点非常明显,每个架构都是物理机部署,配置多种多样、调整非常麻烦,所以需要很多人进行相应的维护,需要准备机器配置调整,整个过程可能需要半天或者一天,整个机器配置也是相对固定的,要么出现分配不合理,要么出现机器过度竞争。
为了解决1.0的问题我们开发网站运营系统,也有很多集群的方式,我们希望通过统一管理、统一配置应用在某个地区需要多少个,这样便于我们管理每个应用,2.0就是针对就是开发者,包括七牛的开发人员,就是官方应用的提供者,还有就是自定义或者第三方,也会通过这种平台发布应用提供服务。
Dora3.0可以归结为一种愿景,就是开发者关注功能开发,不需要关心可用性,包括分布式的各种痛点都不需要关心,包括自己开发当中遇到的问题我们也会帮助解决。有的开发者是机器识别专家,开发出了固体识别应用,作为一个很厉害的角色,建立一个很厉害的模型,请求当中可能包含图片,最终应用会有识别结果,然后直接上线。
我们可以调用图片格式来转换,如果作为标识的话可以调用,进行图片编辑达到客户需求,有的客户可能觉得图片信息非常多,这些都会大家增加处理的时间,但是时间太长不能同步完成,因为作为机器学习专家也不了解,我们的方案就是平台系统提供统一的用户接口,收到客户消息的时候会转化为请求处理调用应用,反馈结果以后我们可以呈现到异步系统当中,通过这种方式开发者对这样的异步请求就不用自己实现,可以通过我们的平台实现。
现在开发者也会遇到一些问题,比如B服务的处理结果是A服务的临时结果,可能需要多个应用通过数据之间传递,如果是异步结果,图片最终也是标识,实际上最终可能反馈图片地址,也就是异步处理结果的存储,今天这些存储需求我们提供统一存储接口和服务,可以提供简单的需求划分服务,开发者可以通过调用服务接口满足存储需求,整个存储和计算也是解耦的,意味着我们的计算系统可以和任何存储系统结合。
前面说过我们会提供更多的基础服务给开发者,也会提供存储服务,就会发现今天的应用关系会越来越复杂,比如网格状态的关系,具体调用哪个服务,服务的地址是在哪里,如果出现问题我们会怎么覆盖,这些都是我们分布式网格应用面对的问题,所以我们提供智能化调度,能够做到通用化的解决,每个应用都有自己的特例,所以调度都有自己的特殊需求,我们可以对每个应用定义操作策略,通过这些操作策略,至于这个服务在哪里完全是由平台决定。
现在假定我们服务一个外卖厂商,每天到十一点钟就是波峰,但是一般来说到深夜的话请求量就会少很多,所以这样外卖厂商的需求就会有很明显的时间性。过去遇到这样的问题,如果是开发者的话可能需要调整,到了高峰的时候调整到可满足的状态,高峰过去的时候为了节约成本就需要持续缩减,调整不好的话就会影响到SLA。按照这个角度来看,我们需要一个自研的方案,现在方案还是相对比较基础,开发者可以根据自己的应用状况。