利用增量的方式减少存储内容的变更，加快索引构建速度。
利用分布式时序锁减少频繁请求带来的压力。
我们可以预留一部分计算资源，放在资源池中，当应用有扩容需求的时候，就向资源池申请资源，当业务负载下降的时候，再把多余的计算资源归还到资源池中。
通过多种弹性机制，能够对系统容量进行精细粒度的管理，使资源的使用量能随着业务流量的变化而调整，从而极大程度的增加资源利用率，大幅降低资源成本。
根据库大小的区别，LSIF的索引构建时间为10秒至数分钟不等，而用户对同一个代码仓库的提交操作峰值可能会达到每分钟近百次，即使我们采用了增量技术也很难满足高频的构建请求，并且提交事件触达和调度任务执行无法保证精准的时序性。综上所述，我们需要一个分布式时序锁来保证任务调度的顺序和尽量减少重复调度。
另外一种是 Serverless 化的容器技术，Serverless 化的容器实例运行在案例隔离的环境中，每个计算节点通过轻量级虚拟化安全沙箱技术完全强隔离。对于使用者而言，无需购买服务器资源即可直接部署容器应用，也无需对集群进行节点维护和容量规划，可以根据应用配置的 CPU 和内存资源量进行按需付费。
在初期，Kubernetes 上主要运行着无状态的 Web 应用。随着技术的成熟和社区的发展，我们看到更多的有状态应用和大数据 /AI 应用负载逐渐迁移到 K8s 上。目前企业的大数据业务还是被 YARN 等调度技术主导，但是 K8s 已经在大数据社区得到更多的关注。Flink、Spark 等开源社区和一系列商业公司如 Cloudera、Databricks、星环都开始加大对 K8s 的支持力度。
应用设计需要考虑读写分离，需要连接不同的数据源处理读写分离的结果，并且这些功能都需要写入应用程序代码。而现在，这些功能可以直接利用数据库的水平扩展能力来实现，数据库技术的发展极大地避免了我们直接和数据层交互。
但通过移除和核心业务无关的内容，从而减小节点数量后，系统的可用率就会大幅增高。上图的左右两边从不同角度对微服务的高可用设计进行了分析。左边是微服务设计应具有的能力，右边是设计高可用微服务架构时应遵循的原则。
支付宝最开始是一个单体应用。随着业务不断发展，支付宝拆分成了多个服务，衍生出了若干代架构。微服务是服务化后的进一步演进，服务的粒度比服务化更细，具有很好的流量管控机制，中间件和编程模型。
使用FASS能够很容易地实现系统功能，但当系统的可用性要求、业务体量增大时，任何一个抖动都可能影响到整个软件系统的可用能力。
