应用之间采用轻量级的通信机制进行通信。这些应用都是围绕具体业务进行构建，可以独立部署、独立迭代，也可能根据业务负载独立进行水平扩展。
如果仅仅依赖于简单的发布脚本进行管理，不但效率很低，还很容易导致顾此失彼，对系统稳定性造成巨大的风险。
能比较方便的实现滚动发布以及应用的优雅上下线。虽然在灰度发布的过程中，依然没有办法直接对流量进行精细粒度控制（
另外，到底规划多大的资源池，也是一件很伤脑筋的事情，池子越大，造成的浪费就越大，但池子太小，又可能满足不了扩容的需求。
在函数计算领域，一切计算资源的申请和调度都由具体的业务事件触发，当业务事件所对应的任务完成之后，计算资源会被立即释放。
而 FaaS 架构的核心在于函数，比应用更偏向系统上层，因此灵活度会降低，不能适配所有的业务场景。
对于非 Java 语言编写的应用，或者没有使用 Spring Cloud 等微服务框架的 Java 应用， SAE 能不能完美支持，并帮助企业降低资源成本呢？
对于开发者而言，要想更好的驾驭微服务架构，需要解决持续集成、服务发现、应用通信、配置管理、流量防护等一系列难题。
能比较方便的实现滚动发布以及应用的优雅上下线。虽然在灰度发布的过程中，依然没有办法直接对流量进行精细粒度控制（引入 Service Mesh 技术能增强流量控制力，不在本文讨论范围），但相比简单的发布脚本，已经有了飞跃性的提升。
从采集系统中收集到的大量原始数据，将进入数据计算层中被进一步整合与计算。
