本文转载自：https://yq.aliyun.com/product/649
企业级分布式应用服务（EDAS，Enterprise Distributed Application Service）是一个以阿里中间件团队多款久经历练的组件产品作为核心基础，所组建的企业云计算解决方案。其充分利用阿里云现有的资源管理和服务体系，引入中间件整套成熟的分布式计算框架——包括分布式应用核心框架，分布式数据化运营，大型应用全生命周期管理等，以应用为中心，集成到企业级分布式应用服务平台上，帮助企业级客户轻松构建并托管分布式应用服务体系。
企业级分布式应用服务与传统IOE架构的区别
传统IOE架构
传统IOE架构
随着时间推移，在出现新业务时，开发人员有两种应对办法。
- 在原应用上增加新业务，将原本较小的应用慢慢扩充成很大的应用；
- 另起炉灶，重新创建针对新业务的新应用。
第一种只适用于业务较少的情况，而在新业务不断增加的情况下，增加新应用也就成了必须。而在这种传统架构中，新增的应用需要一一与原有的底层数据库相连，导致每个应用都需要连接多个数据库。
此外，在传统IOE架构中：
- 每个应用彼此没有太大关系，按烟囱式排列，唯一的共通点在于都与底层的数据库相连；
- 所能处理的应用个数通常比较少，从几个到几十个不等。
总结：在传统IOE架构中，每个应用都比较庞大，同时需要连接多个数据库；架构中的应用数量较少，应用与应用之间的关系简单。
大型分布式应用
大型分布式应用
- 应用彼此间存在复杂的调用关系；
- 架构中可管理的应用多，可能达到成百上千个应用。
其优点在于：这种架构具有良好的可扩展性；而缺点在于管理与运维比较困难，另外由于应用数量多，随着业务增长，应用服务器从十台增加到上百台上千台，这时业务系统故障与机器故障就一定会成为常态。
传统“中心化”系统与阿里的“去中心化”系统架构的区别
传统“中心化”（ESB）系统架构
传统中心化系统架构
- 服务调用者与服务提供者通过企业服务总线相连接；
- ESB成为瓶颈：无论在性能上还是成本消耗上，ESB都会导致瓶颈出现。
阿里“去中心化”系统架构
阿里“去中心化”系统架构
开发这个架构的初衷是为了支撑分布式应用，为了让整个业务系统的扩展没有瓶颈，只需按照业务发展需要进行扩展；上图是最早的雏形。后面为了完善该架构，又做了很多工作，下面将详细说明。
EDAS服务调用
服务接口可视化：让分布式应用不再是黑盒
在最初的架构中，由于看不到任何的数据或者发布了什么服务，开发人员也并不明确每个应用具体包含什么服务，这就像一个黑盒子，所有内容都是一团迷雾。
EDAS在线平台
将服务接口可视化之后，在应用启动时将自动完成服务注册，所发布和消费的服务可以在企业级分布式应用服务平台在线查看，所有内容一目了然。
EDAS服务调用的安全性
EDAS服务调用结构
普通框架是没有安全性可言的，任何人只要知道地址就可以通过服务接口随意进行调用。为此我们针对三种维度的安全性做出了控制：在发布、订阅和调用服务时必须使用合法的安全令牌（access key/secret key）。
- 服务提供者在服务注册中心发布，需要权限AK；
- 服务调用者获得服务提供者的IP，需要授权；
- 服务调用者知道IP，需要调用时，需要正确的AK。
此外，授权数据会下发到服务机器中，避免造成性能瓶颈。
EDAS应用发布
传统集中式模式：
传统的应用包下载模式
l 应用包通过中间文件服务器下载，需受限于其网络带宽；
l 能够发布的机器数量较少
P2P流式应用包分发模式：
P2P应用包分发模式
- 通过EDAS发布控制中心下载；
- 类似P2P下载模式，可快速提供任何一个下载点；
- 支持大规模应用集群发布。
效率对比
随着所发布的应用实例增多，两种发布方式的效率对比如下：
两种发布方式的效率对比
传统集中式（黄色）：随着发布集群规模扩大，耗时急剧增长；P2P流式：采用EDAS燎原发布系统，随着应用实例的增加，发布的时间几乎保持不变。
EDAS扩容
EDAS提供简单方便高效的应用扩容服务。在传统模式中，扩容需运维或开发人员手动布置环境、安装GDP等等；而在P2P流式中，一键即可扩容，只要机器资源足够，在EDAS平台点击“应用扩容”即可完成。
一键扩容界面
EDAS数据化运营
立体监控服务
立体监控服务
EDAS监控服务三个层面的监控数据：资源、容器和应用。
- 系统资源：负载、CPU、内存、 磁盘、网络
- 容器：堆内存、类加载情况、线程池、连接器
- 应用：响应时间、吞吐率、关键链路分析
其中：
系统资源监控
系统资源监控界面
以应用/单机的视角来对基础资源消耗进行监控：
- 可以看到应用下所有节点的平均负载
- 通过技术监控，及时发现问题
- 可以配置报警规则，有异常时快速报警
容器监控
容器监控界面
实时采集容器运行的监控指标，为应用运行环境问题诊断提供依据：
- 堆内存与非堆内存使用情况
- 类加载情况
- 线程运行情况
- 连接器情况
应用实时监控
应用监控界面
监控服务接口的调用量，分布式系统服务的承载能力等，并将其数据化：
- 监控所有服务接口、方法的实时调用情况，调用链的实时查询
- 快速感知系统流量变化，找出系统瓶颈
- 执行实时链路分析
服务综合治理
分布式应用的难点在于集成分布式应用一体化监控、数据化运营以及高效的服务治理。其中，服务有两种角色，服务提供者以及链路负责人。
服务提供者关心：
谁调用了我的服务？ 在什么链路下调用，调用是否合理？调用趋势怎样？产生的瞬间峰值有多少？我的系统是否能支撑，是否需要扩容。
所能采取的应对措施：分组、限流、鉴权、压测。
链路负责人关心：
我依赖了哪些应用、哪些服务？ 整个链路的依赖路径是怎样的？ 哪些容易出错，哪些是链路的处理瓶颈？ 这些依赖如果出错，会有什么影响？
所能采取的应对措施：捕获异常；降级：对于不稳定的服务，是否需要降级；开关：系统压力很大的话，需要关闭不必要的操作；优化：利用服务治理，对瓶颈进行优化。
鹰眼监控
鹰眼监控界面
阿里鹰眼监控平台能够提供应用的响应时间和吞吐量信息，并提供全链路分析功能，从而找出系统热点和瓶颈：
- 完整记录所有故障
- 准确定位故障源
所解决的问题：在开发者参差不齐的情况下，快速完成上层业务目标，完成开发任务；提供透明化的观察方式：快速找出对依赖的压力、易故障点与瓶颈点。
快速找出对依赖的压力、易故障点与瓶颈点
容量压测
容量压测界面
自动计算前端的关键请求与后端机器数量的对应关系，针对机器是否需要加减进行预测：
- 在真实线上的环境基础上，通过调整服务器权重，真实模拟压测情况，评估单机的最大服务能力，从而提供吞吐能力数据以供性能优化参考；
- 用自动化平台，相对科学的精确手段将服务能力数据化；
限流降级
容量是任何一个系统天然存在的上限。客观上讲，不管性能如何，都有可能在业务上超出预期容量。
限流是服务接口提供方对消费方的设置，降级则是服务消费方对服务提供方的设置。通过降级设置，对服务消费方进行保护，一旦超过某个时间，便允许强行断开。通过现有的能量对服务提供方进行保护，在出现超过流量最大能力的时候断开，避免将系统整个拖垮。
弹性伸缩
扩容界面
应用扩容规则和缩容规则一站式设置：根据CPU、LOAD、RT三个指标设置应用的自动扩容或缩容。
EDAS配置推送
大型分布式系统应用配置推送
- 对大型分布式应用配置进行集中管理：修改更容易，通知更及时，配置变更也更安全；
- 对应用配置变更进行历史记录：让应用配置可以轻松回退到前一版本；
- 追踪应用配置推送轨迹：让配置推送所到达机器变得可视化；
- 应用集群推送的规模更大、效率更高。
EDAS灰度系统
EDAS灰度系统
能够允许一部分用户使用新功能，一部分用户使用原有功能，再通过实际测试作出最正确的决定。在业务系统层面，让现有的系统可以平滑升级。