首页
学习
活动
专区
工具
TVP
发布
精选内容/技术社群/优惠产品,尽在小程序
立即前往
您找到你想要的搜索结果了吗?
是的
没有找到

ACP互联网架构认证笔记-EDAS企业级分布式应用服务

EDAS支持语言Java,C++,PHP。EDAS支持Idea,Eclipse;Eclipse插件安装等编译工具。EDAS初级版仅支持应用的部署管理,不支持HSF功能。EDAS基础版不支持RPC框架。 EDAS提供高性能的RPC框架,能构建高可用的分布式系统,考虑各个应用之间的分布式服务发现、服务路由、服务调用以及服务安全等细节。EDAS能单独部署到公司内网(轻量配置中心)。 EDAS HSF服务框架保证用户每次分布式调用的稳定与安全。在服务注册、服务订阅以及服务调用等环节都进行严格的服务鉴权。 HSF设置超时时间 : 通过HSF标签methodSpecials和clientTimeout进行配置,优先级由高到低是 : 客户端methodSpecials>客户端clientTimeout>服务端methodSpecials>服务端clientTimeout EDAS控制台域名 : https://edas.console.aliyun.com EDAS控制台提供日志浏览功能,可查看服务器上所部署的应用运行日志。收敛日志用于将单个应用中类似格式的日志合并和排序。收敛日志配置后需要等待大概5分钟才能生效。 EDAS安装轻量配置中心 : 启动配置中心将会占用此台机器的8080和9600端口,需要在hosts中添加 {轻量配置中心公网 ip} jmenv.tbsite.net。如果此台机器是多网卡的,可启动脚本startup.bat或startup.sh中添加启动参数: -Daddress.server.ip={指定的 IP 地址};通过 -Dhsf.server.ip参数指定要注册服务的IP。 EDAS 服务限流的限流规则(限流规则仅适用于服务提供者)能够从QPS和线程两个维度进行配置。可进行HSF限流和HTTP限流。 EDAS 提供了从响应时间维度对降级规则(降级规则仅仅适合服务消费者)的配置。 EDAS 鹰眼监控系统能够分析分布式系统的每一次系统调用、消息发送和数据库访问。主要包括应用拓扑(可查看调用拓扑和流量QPS),调用链查询(可查看慢业务和出错业务),调用链详情(基于TraceId查询)。 EDAS 提供报警功能,但目前只有短信与邮件通知的方式,报警联系人只能是主账号或者子账号。 EDAS 的应用主要分为两种类型:中间件服务化应用(JAR/WAR包类型的普通应用和Docker应用)和 Kubernetes 应用。Kubernetes应用只支持VPC网络。 EDAS 的应用部署类型有两种 : ECS独占实例(在一台独立的ECS机器上,仅允许部署单独一个应用),Docker实例(单个应用在同一ECS上只能部署一个实例),所以一台ECS可以部署多个实例。 EDAS 能够针对应用的服务调用情况,对服务的QPS、响应时间(RT)和出错率进行全方面的监控。 EDAS 能够针对应用的运行状态,对机器的CPU、内存、负载(Load)、网络和磁盘等基础指标进行详细的监控。EDAS还提供容器监控功能(应用诊断)。基础监控(可提供以应用为维度的数据)面向的是机器,容器监控面向是应用所在的容器。基础监控存在时延,容器监控基本是实时的。 EDAS 提供弹性伸缩功能来根据集群内服务器的CPU、RT和Load三个指标实现自动的扩容或者缩容。 EDAS 对应用的生命周期管理,包括创建、部署、启动/停止和删除(应用删除不可恢复)。可设置JVM参数,Tomcat参数,可对应用的实例分组(可按分组部署应用,添加实例到分组),可配置负载均衡。可配置健康检测URL。 EDAS 包含两种集群:Swarm(部署普通应用和Docker应用)和Kubernetes集群(部署Kubernetes应用)。 EDAS 的配置推送分为全局配置推送和应用内部的配置推送。全局配置推送能操作该用户的所有配置信息,应用内的配置推送只能操作该应用所属的配置信息。一个配置信息由三元组(group、DataId、Content)组成。 EDAS 提供主子账号体系,付费账号都是主账号(拥有EDAS所有资源,所有权限),但不是所有的主账号都是付费账号。1个付费账号最多能绑定5个主账号。RAM子账号由主账号在RAM系统中创建,子账号名要在主账号内唯一。RAM账号有两种授权方式 : RAM授权,EDAS授权(两种方式互斥,有了RAM授权,那么就不能在EDAS中授权),主账号可以对绑定的子账号(用户)进行权限分配、资源分配等。应用的授权只能是主账号对子账号进行授权。 EDAS 的资源主要是指云服务器ECS(Elastic Compute Service)、负载均衡SLB(Server Load Balancer)、专有网络VPC(Virtual Private Cloud)这三类。 VPC环境调用链和监控数据需要有访问请求流量才会产生,如果无客户访问网站,

07

Dubbo在Service Mesh下的思考和方案

Service Mesh这个“热”词是2016年9月被“造”出来,而今年2018年更是被称为service Mesh的关键之年,各家大公司都希望能在这个思潮下领先一步。今天我也分享阿里中间件在这方面的观点,思考和实践。考虑到有些人没了解过Dubbo(集团内以HSF为主)和Servicemesh,先简单介绍下这两个词。Dubbo应该是国内最受欢迎的远程服务框架,在Github上有超过2w的star数,也是阿里分布式架构互联互通的核心所在。跟Dubbo一样,servicemesh也是面向服务互联互通这一问题域,是云原生技术栈的核心之一;大家可以简单理解service mesh就是云原生组织定义的微服务架构解决理念。Dubbo是实现框架,融入servcemesh理念就是我们今天分享的。

02

[新星计划]大数据故事集__从超市收银来看网站系统的发展

一家小超市,一个收银员,同时还兼着干点其他的事情,例如,打扫卫生、摆货。来买东西的人多起来了,排队很长,顾客受不了,于是增加了一个收银台,雇了一个收银员。忙的时候收银员根本没时间去打扫卫生,超市内有点脏,于是雇了一个专门打扫卫生的。随着顾客不断增加,超市也经过好几次装修,由以前的一层变成了两层,这个时候所做的事情就是不断增加收银台、收银员和打扫卫生的人。在超市运转的过程中,老板发现一个现象,有些收银台排很长的队,有些收银台排的人不多,了解后知道是因为收银台太多了,顾客根本看不到现在各个收银台的状况。对于这个现象,一 种简单的方法就是继续加收银台。但一方面,超市没地方可加收银台了,另一方面,作为老板,当然不需要雇太多的人,于是开始研究怎样让顾客了解到收银台的状况,简单地加了一个摄像头和一个大屏幕,在大屏幕上显示目前收银台的状况,这样基本解决了这个问题。排队长度差不多后,又出现了一个现象,就是有些收银台速 度明显比其他的慢,原因是排在这些收银台的顾客买的东西特别 多,于是又想了一招,就是设立专门的10件以下的通道,这样买 东西比较少的顾客就不用排太长的队了,这一招施展后,顾客的满意度明显提升,销售额也好了不少,后来就继续用这招应对团购状况、VIP 状况。在解决了上面的一些烦心事后,老板关注到了一个存在已久的现象,就是白天收银台很闲,晚上则很忙,于是从节省成本上考虑,决定实行部分员工只在晚上上班的机制,白天则关闭一些收银台,顾客仍然可以通过大屏幕看到哪些收银台是关闭的,避免走到没人的收银台去,实行这招后,成本大大降 低了。 这个生活中的例子及其解决的方法,其实和互联网网站发展过程中的一些技术是非常类似的,只是在技术层面用其他名词来 表达了而已,例如,有集群、分工、负载均衡、根据QoS分配资 源等。

02
领券