• 关于

    数据通信应用不可用

    的搜索结果

回答

高可用架构部署方案 高可用架构提供业务分发、弹性扩展、多可用区部署等功能。相较于使用单台ECS实例部署数据库与应用,高可用架构只需简单部署,并且拥有更高的稳定性和可扩展性。 高可用架构特点 高可用架构具有如下特点: 使用多可用区高可用版的负载均衡SLB(Server Load Balancer)对多台云服务器ECS进行流量分发,可扩展应用系统对外服务能力、消除单点故障,提升应用系统的可用性。使用SLB自动跨可用区部署,可加强业务容灾能力。 通过自定义镜像,可以迅速复制出相同应用部署的云服务器ECS实例,之后将实例添加到SLB后端服务器组中,实现业务高可用。SLB可以同时配置四层和七层监听,及轮循、加权轮循、加权最小连接数等多种算法,合理分配后端ECS计算资源。 使用云数据库RDS(Relational Database Service),针对高并发场景进行特殊优化,同时引入线程池、并行复制、隐含主键等功能保证系统持续稳定和高吞吐。云数据库CloudDBA具有完备的性能监控数据,实时监控实例硬件使用指标、慢SQL,并给出各种优化建议,帮您快速定位并解决问题。 部署流程 假设您已拥有一台ECS实例,并且在该实例上部署了数据库与应用,您可以将单实例部署方式转变为单可用区或多可用区高可用架构。本教程指导您如何使用ECS、EIP、SLB和RDS产品来部署多可用区高可用架构。 高可用结构图 使用自定义镜像,部署多台相同配置的ECS实例。详情请参见复制ECS实例。 创建负载均衡SLB实例,将实例添加到SLB后端服务器组中,用于跨可用区挂载ECS实例,实现业务的高可用性。详情请参见配置SLB实例。 使用DTS将ECS实例上的自建数据库迁移至RDS实例,保障业务数据库不中断,自动备份保障数据不丢失。详情请参见迁移自建数据库至RDS实例。 复制ECS实例为了支持跨可用区容灾部署,本教程使用源实例的自定义镜像复制出三台ECS实例。一台与源实例位于同一可用区,两台与源实例位于同一地域下的不同可用区。 前提条件 已注册阿里云账号。如还未注册,请先完成账号注册。 已拥有待复制的源ECS实例。 操作步骤 为ECS实例创建自定义镜像。 登录ECS管理控制台。 在左侧导航栏,单击实例与镜像 > 实例。 在顶部状态栏处,选择地域。 找到目标实例。在操作列中,单击更多 > 磁盘和镜像 > 创建自定义镜像。 输入镜像名称和描述信息。 单击创建。 说明 创建镜像需要一段时间,请您耐心等待。 在左侧导航栏,单击实例与镜像 > 镜像。当目标镜像的进度为100%、状态为可用时,表示镜像创建成功。自定义镜像 使用自定义镜像创建3台ECS实例。 在左侧导航栏,单击实例与镜像 > 镜像。 在自定义镜像页面,找到上一步创建的自定义镜像,在操作列,单击创建实例。 在自定义购买页面,镜像区域已设置为您选择的自定义镜像。根据页面提示,完成其他配置项并购买1台ECS实例。 其中: 地域:选择与源实例相同的地域。 可用区:选择与源实例相同的可用区。 公网带宽:取消勾选分配公网IPv4地址。 更多配置详情,请参见使用向导创建实例。 重复第i步和第ii步。在自定义购买页,镜像区域已设置为您选择的自定义镜像。根据页面提示,完成其他配置项并购买2台实例。 其中: 地域:选择与源实例相同的地域。 可用区:选择与源实例不同的可用区。 实例区域:设置购买实例数量为2。 公网带宽区域:取消勾选分配公网IPv4地址。 更多配置详情,请参见使用向导创建实例。 执行结果 在左侧导航栏,单击实例与镜像 > 实例。在实例列表页面,四台ECS实例的状态均为运行中,可用区两两相同。 ecs_instances 配置SLB实例 ECS实例复制完成后,在支持多可用区的地域创建负载均衡SLB实例,用于跨可用区挂载ECS实例,扩展应用系统对外服务能力、消除单点故障,提升应用系统的可用性。本文介绍SLB实例的部署方法。 前提条件 已复制三台ECS实例,详情请参见复制ECS实例。 四台ECS实例的Web服务均已启动并正常运行。 注意 若Web服务未运行,则SLB实例与ECS实例之间无法正常通信。 操作步骤 创建SLB实例。具体操作,请参见创建负载均衡实例。 本教程使用的配置如下: 地域:必须与ECS实例位于同一地域。 可用区类型:选择多可用区。 实例类型:选择私网。 网络类型:选择专有网络。 主可用区和备可用区:按需配置。 create_slb 将源实例的公网IP转换为弹性公网IP。具体操作,请参见专有网络公网IP转换为弹性公网IP。 说明 为避免影响业务,需保证源实例IP地址不变。因此,需要先将源实例的公网IP转换为弹性公网IP,与源实例解绑后,再将其绑定至高可用版SLB实例上。 ip_eip 解绑源实例与弹性公网IP。 在源实例的IP地址列,单击弹性IP地址链接。 click_eip 在弹性公网IP页面,单击解绑。 unbindEIP 单击确定。更多详情,请参见解绑EIP。 绑定弹性公网IP至SLB实例。 在弹性公网IP页面,找到与源实例解绑后的弹性公网IP。 bindEIP 在操作列,单击绑定。 实例类型选择SLB实例,SLB实例选择刚创建的SLB实例,单击确定。更多详情,请参见绑定SLB实例。 配置SLB实例。具体操作,请参见配置负载均衡实例。 基本配置如下: 在协议&监听页签,完成以下配置。 负载均衡协议:选择TCP。 监听端口:输入80。 调度算法:按需选择。本教程选择轮询。 其他配置使用默认值。 configure_slb 单击下一步。在后端服务器页签,选择默认服务器组,单击继续添加添加ECS实例。 addEcsInstance 勾选源实例和已复制的三台ECS实例,单击下一步:配置权重和端口号。端口配置为80,其他值保持默认,单击下一步。 configure_ports 在健康检查页签,使用默认值,单击下一步。 在配置审核页签,核对信息后,单击提交。 单击确定,返回实例管理页面,单击refresh。 当健康检查状态为正常时,表示后端ECS实例可以正常处理负载均衡转发的请求了。 说明 健康检查需要几分钟时间,请您耐心等待并单击刷新图标查看状态。 health_check 执行结果 为方便测试,本教程分别在四台ECS实例上搭建了静态网页,以标识每台ECS实例。在浏览器中输入负载均衡实例的服务地址,测试负载均衡服务。由于调度算法为轮询,请求会轮流发往每台ECS实例。 slb_test 迁移自建数据库至RDS实例 将源ECS实例上的数据库迁移至高可用版云数据库RDS,可实现数据库服务的高可用性、高可靠性、高安全性和高易用性。本教程以MySQL数据库为例,介绍如何使用DTS将ECS实例上的自建数据库迁移至RDS实例。 前提条件 已配置SLB实例,详情请参见配置SLB实例。 已创建高可用版RDS实例。如未创建,请参见创建RDS for MySQL实例。 已为RDS实例创建账号。如未创建,请参见创建账号和数据库。 已为ECS实例上的自建数据库创建非root账号,用于DTS迁移。 例如,您可以运行以下命令为MySQL数据库创建名为dts、密码为123456的账号。 grant all on . to 'dts'@'%' IDENTIFIED BY '123456'; 背景信息 DTS提供的数据迁移功能能够支持同异构数据源之间的数据迁移,同时提供了库表列三级映射、数据过滤多种ETL特性。您可以使用DTS进行零停机迁移,在迁移过程中,源数据库正常持续提供服务,最大程度降低迁移对业务的影响。DTS支持的数据库类型请参见数据迁移。 操作步骤 登录数据传输DTS控制台。 在左侧导航栏,选择数据迁移。 选择目标RDS实例所在地域,并单击创建迁移任务。 配置迁移任务。 配置任务名称。 您可以使用默认的名称或者自定义名称。 配置源库信息。 DTS支持通过公网、VPN网关、专线及智能网关访问的自建数据库。本教程使用的源数据库为ECS实例上的自建数据库。其他类型数据库的迁移方案,请参见DTS用户手册。 参数名称 描述 实例类型 ECS上的自建数据库。 实例地区 源ECS实例所在地域。 ECS实例ID 源ECS实例的实例ID。DTS支持经典网络及专有网络的ECS实例。 数据库类型 源ECS实例上自建数据库的类型。本示例中,数据库类型为MySQL。 端口 MySQL数据库监听的端口号。 数据库账号 源ECS实例上MySQL数据库的非root账号。 说明 数据库账号必须填写非root账号,否则测试连接时会报错。 数据库密码 非root账号对应的密码。 单击源库信息右下角的测试连接。 当返回的结果为测试通过时,表示源库连接正常。 配置目标库信息。 参数名称 参数值 实例类型 RDS实例。 实例地区 RDS实例所在地域。 RDS实例ID RDS实例的实例ID。 数据库账号 RDS实例的账号。 为RDS实例创建账号,请参见创建账号和数据库。 说明 数据库账号必须填写非root账号,否则测试连接时会报错。 数据库密码 账号对应的密码。 单击目标库信息右下角的测试连接。 当返回的结果为测试通过时,表示目标库连接正常。 单击授权白名单并进入下一步。 配置迁移类型及迁移对象。 配置迁移类型。 业务零停机迁移,请选择:结构迁移+全量数据迁移+增量数据迁移。 全量迁移,请选择:结构迁移+全量数据迁移。 配置迁移对象。 在迁移对象框中单击要迁移的数据库对象,如数据库、表或列,然后单击>添加到已选择对象框中。 说明 默认情况下,数据库对象迁移到ECS自建MySQL实例后,对象名跟本地MySQL实例一致。如果迁移的数据库对象在源实例跟目标实例上名称不同,您需要使用DTS提供的对象名映射功能,详情请参见库表列映射。 单击预检查并启动。 在迁移任务正式启动之前,会预检查连通性、权限及日志格式等。下图表示预检查成功通过。 precheck 预检查通过后,您可以在迁移任务列表中查看迁移任务的迁移状态及进度。 task_result 后续步骤 在应用程序中配置RDS实例的连接地址和账号密码,以连接到RDS实例。您还可以使用数据管理服务DMS(Data Management Service)或客户端管理RDS实例。具体操作,请参见连接MySQL实例。
1934890530796658 2020-03-25 19:18:04 0 浏览量 回答数 0

回答

能干的多了去了看下面弹性计算云服务器ECS:可弹性扩展、安全、稳定、易用的计算服务块存储:可弹性扩展、高性能、高可靠的块级随机存储专有网络 VPC:帮您轻松构建逻辑隔离的专有网络负载均衡:对多台云服务器进行流量分发的负载均衡服务弹性伸缩:自动调整弹性计算资源的管理服务资源编排:批量创建、管理、配置云计算资源容器服务:应用全生命周期管理的Docker服务高性能计算HPC:加速深度学习、渲染和科学计算的GPU物理机批量计算:简单易用的大规模并行批处理计算服务E-MapReduce:基于Hadoop/Spark的大数据处理分析服务数据库云数据库RDS:完全兼容MySQL,SQLServer,PostgreSQL云数据库MongoDB版:三节点副本集保证高可用云数据库Redis版:兼容开源Redis协议的Key-Value类型云数据库Memcache版:在线缓存服务,为热点数据的访问提供高速响应PB级云数据库PetaData:支持PB级海量数据存储的分布式关系型数据库云数据库HybridDB:基于Greenplum Database的MPP数据仓库云数据库OceanBase:金融级高可靠、高性能、分布式自研数据库数据传输:比GoldenGate更易用,阿里异地多活基础架构数据管理:比phpMyadmin更强大,比Navicat更易用存储对象存储OSS:海量、安全和高可靠的云存储服务文件存储:无限扩展、多共享、标准文件协议的文件存储服务归档存储:海量数据的长期归档、备份服务块存储:可弹性扩展、高性能、高可靠的块级随机存储表格存储:高并发、低延时、无限容量的Nosql数据存储服务网络CDN:跨运营商、跨地域全网覆盖的网络加速服务专有网络 VPC:帮您轻松构建逻辑隔离的专有网络高速通道:高速稳定的VPC互联和专线接入服务NAT网关:支持NAT转发、共享带宽的VPC网关大数据(数加)MaxCompute:原名ODPS,是一种快速、完全托管的TB/PB级数据仓库解决方案大数据开发套件:提供可视化开发界面、离线任务调度运维、快速数据集成、多人协同工作等功能,拥有强大的Open API为数据应用开发者提供良好的再创作生态DataV数据可视化:专精于业务数据与地理信息融合的大数据可视化,通过图形界面轻松搭建专业的可视化应用, 满足您日常业务监控、调度、会展演示等多场景使用需求关系网络分析:基于关系网络的大数据可视化分析平台,针对数据情报侦察场景赋能,如打击虚假交易,审理保险骗赔,案件还原研判等推荐引擎:推荐服务框架,用于实时预测用户对物品偏好,支持 A/B Test 效果对比公众趋势分析:利用语义分析、情感算法和机器学习,分析公众对品牌形象、热点事件和公共政策的认知趋势企业图谱:提供企业多维度信息查询,方便企业构建基于企业画像及企业关系网络的风险控制、市场监测等企业级服务数据集成:稳定高效、弹性伸缩的数据同步平台,为阿里云各个云产品提供离线(批量)数据进出通道分析型数据库:在毫秒级针对千亿级数据进行即时的多维分析透视和业务探索流计算:流式大数据分析平台,提供给用户在云上进行流式数据实时化分析工具人工智能机器学习:基于阿里云分布式计算引擎的一款机器学习算法平台,用户通过拖拉拽的方式可视化的操作组件来进行试验,平台提供了丰富的组件,包括数据预处理、特征工程、算法组件、预测与评估语音识别与合成:基于语音识别、语音合成、自然语言理解等技术,为企业在多种实际应用场景下,赋予产品“能听、会说、懂你”式的智能人机交互体验人脸识别:提供图像和视频帧中人脸分析的在线服务,包括人脸检测、人脸特征提取、人脸年龄估计和性别识别、人脸关键点定位等独立服务模块印刷文字识别:将图片中的文字识别出来,包括身份证文字识别、门店招牌识别、行驶证识别、驾驶证识别、名片识别等证件类文字识别场景云安全(云盾)服务器安全(安骑士):由轻量级Agent和云端组成,集检测、修复、防御为一体,提供网站后门查杀、通用Web软件0day漏洞修复、安全基线巡检、主机访问控制等功能,保障服务器安全DDoS高防IP:云盾DDoS高防IP是针对互联网服务器(包括非阿里云主机)在遭受大流量的DDoS攻击后导致服务不可用的情况下,推出的付费增值服务,用户可以通过配置高防IP,将攻击流量引流到高防IP,确保源站的稳定可靠Web应用防火墙:网站必备的一款安全防护产品。 通过分析网站的访问请求、过滤异常攻击,保护网站业务可用及资产数据安全加密服务:满足云上数据加密,密钥管理、加解密运算需求的数据安全解决方案CA证书服务:云上签发Symantec、CFCA、GeoTrust SSL数字证书,部署简单,轻松实现全站HTTPS化,防监听、防劫持,呈现给用户可信的网站访问数据风控:凝聚阿里多年业务风控经验,专业、实时对抗垃圾注册、刷库撞库、活动作弊、论坛灌水等严重威胁互联网业务安全的风险绿网:智能识别文本、图片、视频等多媒体的内容违规风险,如涉黄,暴恐,涉政等,省去90%人力成本安全管家:基于阿里云多年安全实践经验为云上用户提供的全方位安全技术和咨询服务,为云上用户建立和持续优化云安全防御体系,保障用户业务安全云盾混合云:在用户自有IDC、专有云、公共云、混合云等多种业务环境为用户建设涵盖网络安全、应用安全、主机安全、安全态势感知的全方位互联网安全攻防体系态势感知:安全大数据分析平台,通过机器学习和结合全网威胁情报,发现传统防御软件无法覆盖的网络威胁,溯源攻击手段、并且提供可行动的解决方案先知:全球顶尖白帽子和安全公司帮你找漏洞,最私密的安全众测平台。全面体检,提早发现业务漏洞及风险,按效果付费移动安全:为移动APP提供安全漏洞、恶意代码、仿冒应用等检测服务,并可对应用进行安全增强,提高反破解和反逆向能力。互联网中间件企业级分布式应用服务EDAS:以应用为中心的中间件PaaS平台、消息队列MQ:Apache RocketMQ商业版企业级异步通信中间件分布式关系型数据库服务DRDS:水平拆分/读写分离的在线分布式数据库服务云服务总线CSB:企业级互联网能力开放平台业务实施监控服务ARMS:端到端一体化实时监控解决方案产品分析E-MapReduce:基于Hadoop/Spark的大数据处理分析服务云数据库HybirdDB:基于Greenplum Database的MPP数据仓库高性能计算HPC:加速深度学习、渲染和科学计算的GPU物理机大数据计算服务MaxCompute:TB/PB级数据仓库解决方案分析型数据库:海量数据实时高并发在线分析开放搜索:结构化数据搜索托管服务管理与监控云监控:指标监控与报警服务访问控制:管理多因素认证、子账号与授权、角色与STS令牌资源编排:批量创建、管理、配置云计算资源操作审计:详细记录控制台和API操作密钥管理服务:安全、易用、低成本的密钥管理服务应用服务日志服务:针对日志收集、存储、查询和分析的服务开放搜索:结构化数据搜索托管服务性能测试:性能云测试平台,帮您轻松完成系统性能评估邮件推送:事务/批量邮件推送,验证码/通知短信服务API网关:高性能、高可用的API托管服务,低成本开放API物联网套件:助您快速搭建稳定可靠的物联网应用消息服务:大规模、高可靠、高并发访问和超强消息堆积能力视频服务视频点播:安全、弹性、高可定制的点播服务媒体转码:为多媒体数据提供的转码计算服务视频直播:低延迟、高并发的音频视频直播服务移动服务移动推送:移动应用通知与消息推送服务短信服务:验证码和短信通知服务,三网合一快速到达HTTPDNS:移动应用域名防劫持和精确调整服务移动安全:为移动应用提供全生命周期安全服务移动数据分析:移动应用数据采集、分析、展示和数据输出服务移动加速:移动应用访问加速云通信短信服务:验证码和短信通知服务,三网合一快速到达语音服务:语音通知和语音验证,支持多方通话流量服务:轻松玩转手机流量,物联卡专供物联终端使用私密专线:号码隔离,保护双方的隐私信息移动推送:移动应用通知与消息推送服务消息服务:大规模、高可靠、高并发访问和超强消息堆积能力邮件推送:事务邮件、通知邮件和批量邮件的快速发送
巴洛克上校 2019-12-02 00:25:55 0 浏览量 回答数 0

回答

API(Application Programming Interface,应用程序编程接口)是一套用来控制Windows的各个部件(从桌面的外观到为一个新进程分配的内存)的外观和行为的一套预先定义的Windows函数.用户的每个动作都会引发一个或几个函数的运行以告诉Windows发生了什么. 这在某种程度上很象Windows的天然代码.其他的语言只是提供一种能自动而且更容易的访问API的方法.VB在这方面作了很多工作.它完全隐藏了API并且提供了在Windows环境下编程的一种完全不同的方法. 这也就是说,你用VB写出的每行代码都会被VB转换为API函数传递给Windows.例如,Form1.Print...VB 将会以一定的参数(你的代码中提供的,或是默认参数)调用TextOut 这个API函数. 。同样,当你点击窗体上的一个按钮时,Windows会发送一个消息给窗体(这对于你来说是隐藏的),VB获取这个调用并经过分析后生成一个特定事件(Button_Click). API函数包含在Windows系统目录下的动态连接库文件中(如User32.dll,GDI32.dll,Shell32.dll...). API 声明 正如在"什么是API"中所说,API函数包含在位于系统目录下的DLL文件中.你可以自己输入API函数的声明,但VB提供了一种更简单的方法,即使用API Text Viewer. 要想在你的工程中声明API函数,只需运行API Text Viewer,打开Win32api.txt(或.MDB如果你已经把它转换成了数据库的话,这样可以加快速度.注:微软的这个文件有很多的不足,你可以试一下本站提供下载的api32.txt),选择"声明",找到所需函数,点击"添加(Add)"并"复制(Copy)",然后粘贴(Paste)到你的工程里.使用预定义的常量和类型也是同样的方法. 你将会遇到一些问题: 假设你想在你的窗体模块中声明一个函数.粘贴然后运行,VB会告诉你:编译错误...Declare 语句不允许作为类或对象模块中的 Public 成员...看起来很糟糕,其实你需要做的只是在声明前面添加一个Private(如 Private Declare Function...).--不要忘了,可是这将使该函数只在该窗体模块可用. 在有些情况下,你会得到"不明确的名称"这样的提示,这是因为函数.常量或其他的什么东西共用了一个名称.由于绝大多数的函数(也可能是全部,我没有验证过)都进行了别名化,亦即意味着你可以通过Alias子句使用其它的而不是他们原有的名称,你只需简单地改变一下函数名称而它仍然可以正常运行. API 分为四种类型: 远程过程调用(RPC):通过作用在共享数据缓存器上的过程(或任务)实现程序间的通信。 标准查询语言(SQL):是标准的访问数据的查询语言,通过通用数据库实现应用程序间的数据共享。 文件传输:文件传输通过发送格式化文件实现应用程序间数据共享。 信息交付:指松耦合或紧耦合应用程序间的小型格式化信息,通过程序间的直接通信实现数据共享。 当前应用于 API 的标准包括 ANSI 标准 SQL API。另外还有一些应用于其它类型的标准尚在制定之中。API 可以应用于所有计算机平台和操作系统。这些 API 以不同的格式连接数据(如共享数据缓存器、数据库结构、文件框架)。每种数据格式要求以不同的数据命令和参数实现正确的数据通信,但同时也会产生不同类型的错误。因此,除了具备执行数据共享任务所需的知识以外,这些类型的 API 还必须解决很多网络参数问题和可能的差错条件,即每个应用程序都必须清楚自身是否有强大的性能支持程序间通信。相反由于这种 API 只处理一种信息格式,所以该情形下的信息交付 API 只提供较小的命令、网络参数以及差错条件子集。正因为如此,交付 API 方式大大降低了系统复杂性,所以当应用程序需要通过多个平台实现数据共享时,采用信息交付 API 类型是比较理想的选择。 API 与图形用户接口(GUI)或命令接口有着鲜明的差别: API 接口属于一种操作系统或程序接口,而后两者都属于直接用户接口。 有时公司会将 API 作为其公共开放系统。也就是说,公司制定自己的系统接口标准,当需要执行系统整合、自定义和程序应用等操作时,公司所有成员都可以通过该接口标准调用源代码,该接口标准被称之为开放式 API。 da'an'lai'yu'na'w'n答案来源网络,供您参考
问问小秘 2019-12-02 02:13:03 0 浏览量 回答数 0

云数据库新人专场

MySQL年付低至19.9,其它热门产品1元起购!

问题

围绕着内存数据库的4个流言

摘要:Yiftach 表示,历经数年,内存数据库的稳定性已得到了长足的发展,开发者应该理智地看待这个领域所存在的流言,比如内存计算是不可靠和不一致等。 【编者按】作者 ...
sunny夏筱 2019-12-01 21:46:19 7513 浏览量 回答数 3

回答

本文提供完整的阿里云地域和可用区列表。 每个地域完全独立。每个可用区完全隔离,但同一个地域内的可用区之间使用低时延链路相连。地域和可用区之间的关系如下图所示。可用区 地域(Region) 地域是指物理的数据中心。资源创建成功后不能更换地域。当前所有的地域、地域所在城市和 Region ID 的对照关系如下表所示。 说明 不同产品可选择的地域有所不同,请您查看阿里云全球基础设施确认各产品可选择的地域列表。 中国内地 地域名称 所在城市 Region ID 可用区数量 华北 1 青岛 cn-qingdao 2 华北 2 北京 cn-beijing 8 华北 3 张家口 cn-zhangjiakou 2 华北 5 呼和浩特 cn-huhehaote 2 华东 1 杭州 cn-hangzhou 8 华东 2 上海 cn-shanghai 6 华南 1 深圳 cn-shenzhen 5 华南 2 河源 cn-heyuan 2 西南 1 成都 cn-chengdu 2 其他国家和地区 地域名称 所在城市 Region ID 可用区数量 中国香港 香港 cn-hongkong 2 亚太东南 1 新加坡 ap-southeast-1 3 亚太东南 2 悉尼 ap-southeast-2 2 亚太东南 3 吉隆坡 ap-southeast-3 2 亚太东南 5 雅加达 ap-southeast-5 2 亚太南部 1 孟买 ap-south-1 2 亚太东北 1 东京 ap-northeast-1 2 美国西部 1 硅谷 us-west-1 2 美国东部 1 弗吉尼亚 us-east-1 2 欧洲中部 1 法兰克福 eu-central-1 2 英国(伦敦) 伦敦 eu-west-1 2 中东东部 1 迪拜 me-east-1 1 选择地域时,您需要考虑以下几个因素: 地理位置 请根据您以及您目标用户所在的地理位置选择地域。 中国内地 一般情况下建议选择和您目标用户所在地域最为接近的数据中心,可以进一步提升用户访问速度。不过,在基础设施、BGP 网络品质、服务质量、云服务器操作使用与配置等方面,阿里云中国内地地域没有太大区别。BGP 网络可以保证中国内地全部地域的快速访问。 其他国家及地区 其他国家及地区提供国际带宽,主要面向非中国内地内地用户。如果您在中国内地,使用这些地域会有较长的访问延迟,不建议您使用。 对中国香港、东南亚有需求的用户,可以选择中国香港地域、亚太东南 1 地域、亚太东南 3 地域或亚太东南 5 地域。 对日、韩有需求的用户,可以选择亚太东北 1 地域。 对印度有需求的用户,可以选择亚太南部 1 地域。 对澳大利亚地区有需求的用户,可以选择亚太东南 2 地域。 对美洲有需求用户,可以选择美国地域。 对欧洲大陆有需求的用户,可以选择欧洲中部 1 地域。 对中东地区有需求的用户,可以选择中东东部 1 地域。 阿里云产品之间的关系 如果多个阿里云产品一起搭配使用,需要注意: 不同地域的云服务器 ECS、关系型数据库 RDS、对象存储服务 OSS 内网不互通。 不同地域之间的云服务器 ECS 不能跨地域部署负载均衡,即在不同的地域购买的 ECS 实例不支持跨地域部署在同一负载均衡实例下。 资源的价格 不同地域的资源价格可能有差异,请参见阿里云产品定价页面。 关于经营许可证备案 选择地域时您需要考虑某些地区的特殊要求。如您在中国内地地域购买了 ECS 实例,并用于 Web 服务器,您需要完成经营许可证备案。 如您有办理经营许可证备案的需求,请您重点关注: 北京地区企业,请选择购买的地域为华北 2。 广东地区企业,请选择购买的地域为华南 1。 说明 各省通信管理局对经营性备案的审批要求不同,如有变化,请以当地管局经营性备案网站公示内容为准。请参考《各省经营性备案网站链接》。 可用区(Zone) 可用区是指在同一地域内,电力和网络互相独立的物理区域。同一可用区内实例之间的网络延时更小。 在同一地域内可用区与可用区之间内网互通,可用区之间能做到故障隔离。是否将实例放在同一可用区内,主要取决于对容灾能力和网络延时的要求。 如果您的应用需要较高的容灾能力,建议您将实例部署在同一地域的不同可用区内。 如果您的应用要求实例之间的网络延时较低,建议您将实例创建在同一可用区内。 有关地域和可用区的更多信息,请参见 阿里云全球基础设施。
1934890530796658 2020-03-24 14:02:53 0 浏览量 回答数 0

问题

如何整合WAN和因特网云服务?

    企业如何整合WAN和因特网云服务,或者使用公共因特网的 云计算服务?   大多数企业通过在因特网上的SSL VPN来支持远程用户。还有一些用因特网VPN把分支机构连接到数据中心,有效地让企业...
elainebo 2019-12-01 21:04:06 10065 浏览量 回答数 0

问题

围绕着内存数据库的4个流言

摘要:Yiftach 表示,历经数年,内存数据库的稳定性已得到了长足的发展,开发者应该理智地看待这个领域所存在的流言,比如内存计算是不可靠和不一致等。 【编者按】作者...
doudou1 2019-12-01 21:17:05 9279 浏览量 回答数 0

问题

【教程免费下载】Redis开发与运维

前  言 Redis作为基于键值对的NoSQL数据库,具有高性能、丰富的数据结构、持久化、高可用、分布式等特性,同时Redis本身非常稳定,已经得到业界的广泛认可和使用。掌握Redis已经逐步成为...
知与谁同 2019-12-01 22:07:46 2741 浏览量 回答数 2

问题

独家| 对阿里云庞大的技术产品一知半解?这里是16大领域,超过4000个技术问答

hi developers~ 四月初,为解决大家对于云计算问题难以找到正确答案的难题,四位热心大咖做了一件“轰轰烈烈”的事情~我们将阿里云帮助文档中频率出现最高的内容全部整理出来,供大家参考以及查阅...
问问小秘 2020-04-03 13:39:45 16752 浏览量 回答数 11

问题

HBase 高可用原理与实践

转载自:http://www.hbase.group/article/42 前言 前段时间有套线上HBase出了点小问题,导致该套HBase集群服务停止了2个小时,从而造成使用该套HBase作为...
pandacats 2019-12-20 21:19:02 0 浏览量 回答数 0

回答

服务网格 ASM 主要适用于需要对应用服务进行流量管理、安全管理、故障恢复、观测监控以及微服务架构迁移的应用场景。本文介绍 ASM 的常见应用场景。 流量管理 通过 ASM,可以轻松实现基于配置的流量管理: 将流量管理与基础设施管理分隔开来,并提供了许多立于应用代码之外的流量管理功能,在部署规模逐步扩大的过程中帮助简化流量管理。 管理服务网格的服务发现、流量路由和负载均衡,简化服务级属性的配置,例如超时和重试等。 服务安全 通过 ASM,可以轻松实现服务之间的双向 TLS 认证: 支持以渐进方式实现 mTLS 双向认证,可以确保服务间通信以及最终用户与服务之间通信的安全。 双向 TLS 认证在实现过程中不需要更改服务代码,可以为每个服务提供基于角色的强大身份认证机制,以实现跨集群、跨云端的交互操作。 通过 ASM,可以轻松实现服务之间的授权: 借助 Istio 授权机制,ASM 确保只能从经过严格身份认证和授权的客户端访问包含敏感数据的服务。 支持对网格中的服务进行基于命名空间级别、服务级别和方法级别的访问权限控制,包括使用基于角色的语义、服务到服务和最终用户到服务的授权,并在角色和角色绑定方面提供灵活的自定义属性支持。 通过 ASM,可以轻松实现密钥管理: 基于 Istio 的密钥管理系统,支持自动生成、分发、轮换与撤消密钥和证书。 故障恢复 通过 ASM,可以轻松实现开箱即用的故障恢复功能: 分布式系统存在高度复杂性,在基础设施、应用逻辑、运维流程等环节都可能存在稳定性风险导致业务系统的失效。 提供了基于 Istio 的混沌工程能力,包括如何使用连接池配置和异常检测实现熔断能力,支持针对服务的重试和故障注入等能力。 服务可观测性 通过 ASM,可以轻松实现服务之间的可观测性,借助强大可靠且易于使用的监控功能,快速有效地检测和修复问题。 通过集成的阿里云链路追踪服务,为分布式应用的开发者提供完整的调用链路还原、调用请求量统计、链路拓扑、应用依赖分析等工具,帮助开发者快速分析和诊断分布式应用架构下的性能瓶颈,提高开发诊断效率。 微服务架构 通过 ASM,可以实现敏捷开发和部署落地,加速企业业务迭代。企业生产环境中,通过合理微服务拆分,将每个微服务应用存储在阿里云镜像仓库帮您管理。您只需迭代每个微服务应用,由阿里云提供调度、编排、部署和灰度发布能力。 负载均衡和服务发现支持 4 层和 7 层的请求转发和后端绑定。 丰富的调度和异常恢复策略支持服务级别的亲和性调度,支持跨可用区的高可用和灾难恢复。 微服务监控和弹性伸缩支持微服务和容器级别的监控,支持微服务的自动伸缩。
1934890530796658 2020-03-20 19:39:40 0 浏览量 回答数 0

回答

Logistics Sci—Tech No.10,2008 · 军事物流· 物流科技2008年第1O期 摘 要:现代军事物流是信息化战争后勤保障的重要支 撑。随着信息技术的不断发展, 卫星定位系统逐渐应用于军 事物流领域,成为现代军队战斗力的倍增器。文章介绍了卫 星定位系统概况, 阐述了卫星定位系统在军事物流领域的应 用现状,对军事物流领域应用卫星定位系统的前景及思路进 行了探讨。 关键词:卫星定位系统;军事物流;应用 中图分类号:E075 文献标识码:A 文章编号:1002—3100 f2008) 10—0071—03 Abstract: Modern military logistics is one of the important pans of logistics under informationization war. Nowadays, satellite positioning system is applied in the field of military logistics gradually with the development of information technology. This paper introduces the general situation of satellite positioning system,analyses its current and future application in the field of military logistics, discusses the development ideaS of applying satellite positioning system in the field of military logistics. Key words:satellite positioning sy stem;military logistics;application 军事物流是指军事物资经由筹措、运输、储存、包装、维修保养、配送等环节,从供应地向部队用户有序流动的过程ll】。 卫星定位系统作为当今最先进的信息设施之一,是提高军事物流信息化建设水平,增强部队战斗力不可缺少的技术工具和手段 。 在现代军事物流活动中,重视这~ 技术的创新和推广应用,将快速实现对军事物流的实时监控,从而有效提高信息化战争的后 勤保障效能 1 卫星定位系统概况 卫星定位系统是利用多颗人造地球卫星、地面控制设备和信号接收设备,对地面静态或动态目标进行定位和导航的系统。 目前,全球正在运行或研制中的卫星定位系统有美国全球定位系统(Global Positioning System.GPS)、俄罗斯全球卫星导航系 统(GLONASS)、欧盟伽利略导航卫星系统计划(GALILEO)和中国“北斗一号” 卫星导航定位系统。 GPS是美国军方20世纪70年代研制的军民两用卫星定位系统,军用加密,民用降低定位精度后在全球使用,在用户数量 上处于霸主地位。GLONASS是由原苏联(现由俄罗斯)国防部独立研制和控制的第二代军用卫星导航系统, 其建立目的主要 是避免在军事上受制于美国。由于种种原因, 目前处于“半可用”状态,市场中GLONASS设备极少,产品多是内置GLONASS 和GPS两种接收装置, 以提高精度和可用性。同样出于避免受制于美国的目的.欧盟2003年也开始了GALILEO计划.建造世 界上第一个非军方控制和管理的民用』J星导航定位系统.预计2010年正式投入商业运行 这3个系统都是全球卫星导航定位 系统,导航范围覆盖全球。中国“北斗一号” 系统则是覆盖我国本土的区域导航定位系统, 目前拥有5颗导航卫星,除具有导 航功能外,还具有短报文通信和精密授时功能。在2008年南方抗击雨雪冰冻和四川特大地震灾害中初露锋芒.在北京奥运会 期间将为交通调度和场馆监控提供服务。 GPS导航系统是被动式伪码单向测距三维导航,采用的是无源定位。定位数据由用户设备独立解算, 因此不能提供通讯服 务。 “北斗” 系统是主动式双向测距二维导航,采用的是有源定位.定位数据由地面控制中心解算后提供给用户,用户需要通 过地面中心站联系及地面中心站的传输;因此可以提供通讯服务,通讯不必通过其他的通讯卫星.实现了一星多用。 GPS、GLONASS、GA[ ILEO和“北斗” 系统对比见表1 2 卫星定位系统在军事物流领域的应用现状 卫星定位系统的建立源于军事目的,美国GPS在近几场局部战争中应用于指挥控制、兵力投送、精确制导、目标侦察、战 场救援、军事物流等各个方面,成为美军战斗力的倍增器。尤其在伊拉克战争中,超大量战争物资运输保障,战时补给,大兵 团诸军兵种的专用装备保障,没有GPS 的导航和定位,军事物流则难以实现适时、快速、精确的保障,也就很难在短时间内 结束战斗并取得战斗的胜利 。近几年,我国加紧研发中国“北斗” 系统,引进对GPS的应用.逐渐将卫星定位系统应用于军 收稿日期:2008~06—24 作者简介: 白 娟(1973一),女,山东济南人,后勤指挥学院研究生五队硕士研究生,研究方向:军事物流信息化建设。 卫星定位系统在军事物流领域应用现状及前景探讨 表1 GPS、GLONASS、GALILEO和“北斗” 系统对比表 美国GPS 俄罗斯GL0NASS 欧盟GALILE0 中国“北斗” 系统 研制时间 20世纪70年代 20世纪70年代中期 1999年2月 2000生 卫星个数 28 24 30 5 轨道高度(KM) 20 186 l9 l00 23 222 36 0o0 运行周期 l1:15:44 l1:15:00 14:22:00 l1:58:00 民用单频CA码 民用单频CA码 CA码 调制码 军用双频P码 军用双频P码 P码 定位精度 CA码约l2米 水平方向约l6米 水平定位精度优于10米 约30米 P码小于10米 垂直方向约25米 覆盖范围 全球 全球 全球 中国及周边地区 主要功能 定位导航导航定位、短报文通信、 . 精密授时 定位导航,精密授时 定位导航.精密授时 精密授时 优点优点:投资小、用户设 : 全天候: 全球覆盖; 三维 由于GL0NASS卫星发 该系统提供三种导航定 备价廉 。定速定时高精度缺点: 不能覆 :快速省时高效 射的载波频率不同. 可 位信号 率: 免费信号、收 盖两极地区. 赤道附近 系统特点 : 应用广泛多功能。缺点:信 以防止整个卫星导航系 费加密信号 、号存在易损性和丢失性满足更高 定位精度差:不能满足 . 抗干扰 统同时被敌方干扰. 因 要求的收费加密信号 , 能力差高动态和保密的军事用 : 定位精度受美国军方限 而具有更强的抗干扰能 供各种不同的用户使用 户要求 . 书1 力 用户数量受一 定限制 民用领域: 用于航空/航海导航、 大地测量、石油勘探、地震测量、 由于种种原因. 目前处 野外救生、探险、森林防火、飞 于“半可用” 状态. 市 机播种、农田耕种、车辆自动导 场中GL0NASS设备极 2010年正式投入商业运 使用者基本是军队等国 应用现状 航监控、机场,港13'交通管理等诸 少, 而且多是美国产品, 行 家用户. 市面上很少有 多方面军用领域: 美军用于指挥 内置GL0NASS和GPS 北斗星的接收机出售 控制.兵力投送、精确制导、目 两种接收装置. 以提高 标侦察、战场救援、军事物流等 精度和可用性 方面 主动式双向测距二维导 定位原理 被动式伪码单向测距三维导航航。定位数据由地面控 , 定位数据由用户设备独立解算 制中心解算后提供给用 事物流领域,但仍处于初级阶段,其应用主要体现在以下几个方面 2.1 对军事物资运输的监控调度 通过将卫星定位系统的用户接收机安装在军用车辆、飞机、舰船上实现对军事物资运输的监控调度。利用卫星定位系统和 电子地图GIS可实时显示出运输工具的实际位置与轨迹,从而对其进行实时、有效的定位、监控和调度。实现方式是运输工具 通过终端接收导航定位信息,经处理后,将数据按一定格式由无线电收发机传送到指挥中心,指挥中心接收机将接收到的数据 输入计算机,经处理,在电子地图中显示运输工具和物资位置。 2.2 对军事运输路线的导航规划 选择正确、便捷的运输路线,是实现军事物流快速保障的前提条件。运用卫星定位系统的导航规划功能则充分满足了这一 需求。卫星导航系统的路线规划功能包括自动、手动和指令式3种。自动式路线规划是由驾驶员确定起点和终点,由计算机软 件按照要求自动设计最佳路线。手动式路线规划是驾驶员根据自己的目的地设计起点和终点等,系统在电子地图上设计路线, 同时显示运行途径和方向。指令式路线规划是指指挥中心对行驶站点的时间和路线能作出有效反应,提出路线的规划,并给运 输工具发出导航指令。实现方式是将卫星定位终端与计算机相连接,实现数据的实时传输,以电子地图的形式显示导航数据。 2-3 对需求信息的查询 在军事运输途中,卫星定位系统可以提供主要物标,在电子地图上根据需要进行查询,显示其位置。同时指挥中心可以利 用监测控制台对所在位置进行查询,车辆及物资信息则以数字形式在指挥中心的地图上显示出来。此外,利用卫星定位系统记 录和储存保障物资详细的运输内容和信息,消除了很多需要人工处理的环节,使得整个军事物流系统中所有程序及信息系统实 现信息传输的快速、准确、一致。 2 4 对险情、事故的紧急救援 72 {) ij¨P S t ~1 t lj 20~)g.{O 卫星定位系统在军事物流领域应用现状及前景探讨 通过卫星系统定位和监控管理系统可以对遇有险情或发生事故的地方进行紧急援助。监控台的电子地图显示求助信息和报 警目标,规划最优援助方案,并以报警声光提醒监控人员进行应急处理。我国自主研制的“北斗一号”卫星定位系统在四JIl汶 JIl地震救援中不仅实时监测到了救援部队的行进状态,而且在通信中断的情况下充分发挥了其短报文通信的功能,保障了救援 的顺利展开。 3 卫星定位系统在军事物流领域的应用前景 3.1 应用于建立网络化军事物流保障体系 军事物流保障网络化是信息化条件下一体化联合作战的要求,是指通过多种信息技术将各个物资保障网点(如物流中心、 后方基地、仓库等)集成为军事物流保障网,实现物流配送实体网络和信息网络的“无缝链接”,从而在战争中以实时的快速 反应、精确的投向投量和灵敏高效的指挥调度实现适时、适地、适量的后勤保障。卫星定位系统在军事物流网络化建设中具有 不可替代的作用,主要体现在功能多、精度高、覆盖面广,是构建网络的最佳技术设施和应用平台; 二是构筑在卫星定位系 统的网络公共平台,具有开放度高、资源共享程度高等优点,无地域性限制的信息获取,提高了定位系统的利用率。 3.2 应用于军事物流资产可视化管理 信息化条件下,战场透明度越来越高,物资储存和运输的可见性变得至关重要。物流资产可视化管理是依赖计算机技术、 网络技术、数据库技术、自动识别技术、卫星定位技术等多种信息技术,实现物资在储、在运、在处理全过程的数据跟踪可 视.使得部队指挥官可以不问断、可视化地掌握全部后勤资源的动态情况,全程跟踪“人员流”、 “装备流” 和“物资流”,并 指挥和控制其接收、分发和调换。在运资产通常是装载于某种运输工具,如火车、飞机、轮船、汽车等。实现在运资产可视 化,首先要掌握运输工具的实时位置,而掌握移动中的运输工具的实时位置离不开卫星定位系统。卫星定位系统在军事物流资 产可视化的应用,集中在两个主要方面:其~ 。卫星定位系统用于提供运输工具的位置数据。其二,卫星通信可使控制站和驾 驶员实现双向信息交流。有效运用卫星定位系统,形成有力的统一组织指挥中心,能够提高物流管理的透明度,为优质、高效 的物流保障提供坚实的技术平台。 3-3 应用于实现精确主动配送式保障模式 精确主动配送式保障是指在精确预测部队需求的前提下,打破过去那种逐级前送、被动等待的后勤保障运行机制,通过将 所需物资主动配送到战斗单位乃至士兵,使补给速度发生质的变化,是现代化军事物流保障模式的研究方向。物流配送的过程 是实物的空间位置转移过程,在物流配送过程中,涉及到货物的运输、仓储、装卸、送递等处理环节,对各个环节涉及的问题 如运输路线的选择、仓库位置的选择、仓库的容量设置、合理装卸策略、运输车辆的调度和投递路线的选择等进行有效的管理 和决策分析将有助于物流配送有效地利用现有资源, 降低消耗,提高效率。卫星定位系统解决了物流配送过程中运输车辆调度 和投递路线选择、精确定位部队用户等诸多问题,有利于提高物资的补给速度,从而实现精确主动配送式保障。 4 军事物流领域应用卫星定位系统的发展思路 目前.卫星定位系统在军事物流信息化建设的应用基本上还处于起步阶段,要实现这项技术的全面推广和运用.建立适应 我军后勤发展的军事物流系统,可以从以下几个方面着手: (1)加强卫星定位系统在军事物流领域推广应用的组织领导。由总部牵头统一组织规划、统一技术体制、统一信息标准、 统一软件开发,并与作战指挥系统兼容,从研究开始就杜绝卫星定位系统在军事物流领域应用中各自为政、互不统一、缺乏系 统集成等问题的出现。再就是加强军地合作,把军队的资源优势和地方的技术优势整合起来,共同研制、发展新技术,以保证 其在军事物流领域应用的有效性 (2)开展规划研究、突破关键技术。从顶层对研究项目进行规划设计,并根据我军现状确定当前及今后一段时期内卫星 定位系统在军事物流领域应用的重点和难点。必须立足于新技术引进后的自主开发和创新,形成自己的技术.组织科研力量协 力攻关,力争解决自主技术与外军技术相结合、抗干扰、精度限制、加密技术等关键难题,为卫星定位系统在军事物流信息化 建设中的进一步应用做好准备。 (3)研发基于卫星定位系统等先进信息技术的军事物流应用平台, 建设相关实验室,着眼未来信息化战争实际.跟踪国 内外、军内外卫星定位系统应用研究发展动态,积极探索卫星定位系统在我军军事物流领域的应用研究.以带动全军后勤信息 化的发展。 (4)在后勤保障部队试点后推广。选择部分后勤保障部队进行实验试点,使得卫星定位系统的应用真正与部队建设的实 际结合起来,通过解决实际中遇到的各种问题,不断完善卫星定位系统在军事物流建设的应用研究。从而最大限度地挖掘整个 军事物流系统的保障潜力,使我军后勤保障实现质的飞跃。 参考文献: [1】王宗喜,徐东.军事物流学[M].北京:清华大学出版,2007. 【2] 谭建中.物流信息技术【M】.北京: 中国物资出版社,2008. 【3】戢觉佑,王京海.美军后勤理论与实践【M】.天津:海军后勤学院,2003. f4】徐卫东.GPS+GLONASS+GALILEO三星跟踪技术【JJ_全球定位系统,2006(1):16—18 { 《' ;H s ( {l 200S {f) 73
管理贝贝 2019-12-02 01:16:43 0 浏览量 回答数 0

回答

云服务器(Elastic Compute Service,简称ECS)是阿里云提供的性能卓越、稳定可靠、弹性扩展的IaaS(Infrastructure as a Service)级别云计算服务。云服务器ECS免去了您采购IT硬件的前期准备,让您像使用水、电、天然气等公共资源一样便捷、高效地使用服务器,实现计算资源的即开即用和弹性伸缩。阿里云ECS持续提供创新型服务器,解决多种业务需求,助力您的业务发展。 为什么选择云服务器ECS 选择云服务器ECS,您可以轻松构建具有以下优势的计算资源: 无需自建机房,无需采购以及配置硬件设施。 分钟级交付,快速部署,缩短应用上线周期。 快速接入部署在全球范围内的数据中心和BGP机房。 成本透明,按需使用,支持根据业务波动随时扩展和释放资源。 提供GPU和FPGA等异构计算服务器、弹性裸金属服务器以及通用的x86架构服务器。 支持通过内网访问其他阿里云服务,形成丰富的行业解决方案,降低公网流量成本。 提供虚拟防火墙、角色权限控制、内网隔离、防病毒攻击及流量监控等多重安全方案。 提供性能监控框架和主动运维体系。 提供行业通用标准API,提高易用性和适用性。 更多选择理由,请参见云服务器ECS的优势和应用场景。 产品架构 云服务器ECS主要包含以下功能组件: 实例:等同于一台虚拟服务器,内含CPU、内存、操作系统、网络配置、磁盘等基础的计算组件。实例的计算性能、内存性能和适用业务场景由实例规格决定,其具体性能指标包括实例vCPU核数、内存大小、网络性能等。 镜像:提供实例的操作系统、初始化应用数据及预装的软件。操作系统支持多种Linux发行版和多种Windows Server版本。 块存储:块设备类型产品,具备高性能和低时延的特性。提供基于分布式存储架构的云盘、共享块存储以及基于物理机本地存储的本地盘。 快照:某一时间点一块云盘或共享块存储的数据状态文件。常用于数据备份、数据恢复和制作自定义镜像等。 安全组:由同一地域内具有相同保护需求并相互信任的实例组成,是一种虚拟防火墙,用于设置实例的网络访问控制。 网络: 专有网络(Virtual Private Cloud):逻辑上彻底隔离的云上私有网络。您可以自行分配私网IP地址范围、配置路由表和网关等。 经典网络:所有经典网络类型实例都建立在一个共用的基础网络上。由阿里云统一规划和管理网络配置。 更多功能组件详情,请参见云服务器ECS产品详情页。 以下为云服务器ECS的产品组件架构图,图中涉及的功能组件的详细介绍请参见相应的帮助文档。whatIsECS 产品定价 云服务器ECS支持包年包月、按量付费、预留实例券、抢占式实例等多种账单计算模式。更多详情,请参见计费概述和云产品定价页。 管理工具 通过注册阿里云账号,您可以在任何地域下,通过阿里云提供的以下途径创建、使用或者释放云服务器ECS: ECS管理控制台:具有交互式操作的Web服务页面。关于管理控制台的操作,请参见常用操作导航。 ECS API:支持GET和POST请求的RPC风格API。关于API说明,请参见API参考。以下为调用云服务器ECS API的常用开发者工具: 命令行工具CLI:基于阿里云API建立的灵活且易于扩展的管理工具。您可基于命令行工具封装阿里云的原生API,扩展出您需要的功能。 OpenAPI Explorer:提供快速检索接口、在线调用API和动态生成SDK示例代码等服务。 阿里云SDK:提供Java、Python、PHP等多种编程语言的SDK。 资源编排(Resource Orchestration Service):通过创建一个描述您所需的所有阿里云资源的模板,然后资源编排将根据模板,自动创建和配置资源。 运维编排服务(Operation Orchestration Service):自动化管理和执行运维任务。您可以在执行模板中定义执行任务、执行顺序、执行输入和输出等,通过执行模板达到自动化完成运维任务的目的。 Terraform:能够通过配置文件在阿里云以及其他支持Terraform的云商平台调用计算资源,并对其进行版本控制的开源工具。 阿里云App:移动端类型的管理工具。 Alibaba Cloud Toolkit:阿里云针对IDE平台为开发者提供的一款插件,用于帮助您高效开发并部署适合在云端运行的应用。 部署建议 您可以从以下维度考虑如何启动并使用云服务器ECS: 地域和可用区 地域指阿里云的数据中心,地域和可用区决定了ECS实例所在的物理位置。一旦成功创建实例后,其元数据(仅专有网络VPC类型ECS实例支持获取元数据)将确定下来,并无法更换地域。您可以从用户地理位置、阿里云产品发布情况、应用可用性、以及是否需要内网通信等因素选择地域和可用区。例如,如果您同时需要通过阿里云内网使用云数据库RDS,RDS实例和ECS实例必须处于同一地域中。更多详情,请参见地域和可用区。 高可用性 为保证业务处理的正确性和服务不中断,建议您通过快照实现数据备份,通过跨可用区、部署集、负载均衡(Server Load Balancer)等实现应用容灾。 网络规划 阿里云推荐您使用专有网络VPC,可自行规划私网IP,全面支持新功能和新型实例规格。此外,专有网络VPC支持多业务系统隔离和多地域部署系统的使用场景。更多详情,请参见专有网络(Virtual Private Cloud)。 安全方案 您可以使用云服务器ECS的安全组,控制ECS实例的出入网访问策略以及端口监听状态。对于部署在云服务器ECS上的应用,阿里云为您提供了免费的DDoS基础防护和基础安全服务,此外您还可以使用阿里云云盾,例如: 通过DDoS高防IP保障源站的稳定可靠。更多详情,请参见DDoS高防IP文档。 通过云安全中心保障云服务器ECS的安全。更多详情,请参见云安全中心文档。 相关服务 使用云服务器ECS的同时,您还可以选择以下阿里云服务: 根据业务需求和策略的变化,使用弹性伸缩(Auto Scaling)自动调整云服务器ECS的数量。更多详情,请参见弹性伸缩。 使用专有宿主机(Dedicated Host)部署ECS实例,可让您独享物理服务器资源、降低上云和业务部署调整的成本、满足严格的合规和监管要求。更多详情,请参见专有宿主机DDH。 使用容器服务Kubernetes版在一组云服务器ECS上通过Docker容器管理应用生命周期。更多详情,请参见容器服务Kubernetes版。 通过负载均衡(Server Load Balancer)对多台云服务器ECS实现流量分发的负载均衡目的。更多详情,请参见负载均衡。 通过云监控(CloudMonitor)制定实例、系统盘和公网带宽等的监控方案。更多详情,请参见云监控。 在同一阿里云地域下,采用关系型云数据库(Relational Database Service)作为云服务器ECS的数据库应用是典型的业务访问架构,可极大降低网络延时和公网访问费用,并实现云数据库RDS的最佳性能。云数据库RDS支持多种数据库引擎,包括MySQL、SQL Server、PostgreSQL、PPAS和MariaDB。更多详情,请参见关系型云数据库。 在云市场获取由第三方服务商提供的基础软件、企业软件、网站建设、代运维、云安全、数据及API、解决方案等相关的各类软件和服务。您也可以成为云市场服务供应商,提供软件应用及服务。更多详情,请参见云市场文档。 更多方案,请参见阿里云解决方案。
1934890530796658 2020-03-24 14:03:02 0 浏览量 回答数 0

回答

"静态页面和站点适合用于内容少、更新频率低的场景,反之,就需要动态站点了。比如 淘宝的商品页面,采用静态页面方式管理商品信息是不现实的。如何根据用户请求动态地返 回结果呢?我们来看两种常见的解决方案:  Web 单体应用:所有的应用逻辑都在一个应用中完成,结合数据库,这种分层架构可 以快速实现一些复杂度较低的应用;  微服务应用:随着业务发展,功能多了,访问量高了,团队大了,这时候一般就需要将 单体应用中的逻辑拆分成多个执行单元,比如商品页面上的评论信息、售卖信息、配送 信息等,都可以对应一个单独的微服务。这种架构的好处是每个单元是高度自治的,易 于开发(比如使用不同技术)、部署和扩展。但是这种架构也引入了分布式系统的一些 问题,如服务间通信的负载均衡、失败处理等。 处在不同阶段不同规模的组织可以选择适合自身的方式,来解决它面临的首要业务问 题,淘宝最初被人们接受一定不是因为它使用了哪种技术架构。但是无论选择哪种架构,上 面提到的 Serverless 原生心智都有助于我们专注业务。比如:  是否需要自己购置服务器安装数据库,实现高可用、管理备份、升级版本等,还是可以 把这些事情交给托管的服务如 RDS;是否可使用表格存储、Serverless HBase 等 Serverless 数据库服务,实现按使用的弹性扩容缩容和付费; 单体应用是需要自己购置服务器运行,还是可以交给托管服务,如函数计算和 Serverless 应用引擎;  是否可以通过函数来实现轻量级微服务,依赖函数计算提供的负载均衡、自动伸缩、按 需付费、日志采集、系统监控等能力;  基于 Spring Cloud、Dubbo、HSF 等实现的微服务应用是否需要自己购置服务器 部署应用,管理服务发现,负载均衡,弹性伸缩,熔断,系统监控等,还是可以将这些 工作交给诸如 Serverless 应用引擎服务。 架构引入了 API 网关、函数计算或者 Serverless 应用引擎来实现计算 层,将大量的工作交给了云服务完成,让用户最大程度上专注实现业务逻辑。其中系统内部 多个微服务的交互如下图所示,通过提供一个商品聚合服务,将内部的多个微服务统一呈现 给外部。这里的微服务可以通过 SAE 或者函数实现。
1358896759097293 2021-03-24 13:51:54 0 浏览量 回答数 0

回答

MQTT协议 MQTT(Message Queuing Telemetry Transport,消息队列遥测传输)最早是IBM开发的一个即时通讯协议,MQTT协议是为大量计算能力有限且工作在低带宽、不可靠网络的远程传感器和控制设备通讯而设计的一种协议。 MQTT协议的优势是可以支持所有平台,它几乎可以把所有的联网物品和互联网连接起来。 它具有以下主要的几项特性:1、使用发布/订阅消息模式,提供一对多的消息发布和应用程序之间的解耦;2、消息传输不需要知道负载内容;3、使用 TCP/IP 提供网络连接;4、有三种消息发布的服务质量:QoS 0:“最多一次”,消息发布完全依赖底层 TCP/IP 网络。分发的消息可能丢失或重复。例如,这个等级可用于环境传感器数据,单次的数据丢失没关系,因为不久后还会有第二次发送。QoS 1:“至少一次”,确保消息可以到达,但消息可能会重复。QoS 2:“只有一次”,确保消息只到达一次。例如,这个等级可用在一个计费系统中,这里如果消息重复或丢失会导致不正确的收费。5、小型传输,开销很小(固定长度的头部是 2 字节),协议交换最小化,以降低网络流量;6、使用 Last Will 和 Testament 特性通知有关各方客户端异常中断的机制;在MQTT协议中,一个MQTT数据包由:固定头(Fixed header)、 可变头(Variable header)、 消息体(payload)三部分构成。MQTT的传输格式非常精小,最小的数据包只有2个bit,且无应用消息头。下图是MQTT为可靠传递消息的三种消息发布服务质量 发布/订阅模型允许MQTT客户端以一对一、一对多和多对一方式进行通讯。 下图是MQTT的发布/订阅消息模式 CoAP协议 CoAP是受限制的应用协议(Constrained Application Protocol)的代名词。由于目前物联网中的很多设备都是资源受限型的,所以只有少量的内存空间和有限的计算能力,传统的HTTP协议在物联网应用中就会显得过于庞大而不适用。因此,IETF的CoRE工作组提出了一种基于REST架构、传输层为UDP、网络层为6LowPAN(面向低功耗无线局域网的IPv6)的CoAP协议。 CoAP采用与HTTP协议相同的请求响应工作模式。CoAP协议共有4中不同的消息类型。CON——需要被确认的请求,如果CON请求被发送,那么对方必须做出响应。NON——不需要被确认的请求,如果NON请求被发送,那么对方不必做出回应。ACK——应答消息,接受到CON消息的响应。RST——复位消息,当接收者接受到的消息包含一个错误,接受者解析消息或者不再关心发送者发送的内容,那么复位消息将会被发送。 CoAP消息格式使用简单的二进制格式,最小为4个字节。 一个消息=固定长度的头部header + 可选个数的option + 负载payload。Payload的长度根据数据报长度来计算。 主要是一对一的协议 举个例子: 比如某个设备需要从服务器端查询当前温度信息。 请求消息(CON): GET /temperature , 请求内容会被包在CON消息里面响应消息 (ACK): 2.05 Content “22.5 C” ,响应内容会被放在ACK消息里面 CoAP与MQTT的区别 MQTT和CoAP都是行之有效的物联网协议,但两者还是有很大区别的,比如MQTT协议是基于TCP,而CoAP协议是基于UDP。从应用方向来分析,主要区别有以下几点: 1、MQTT协议不支持带有类型或者其它帮助Clients理解的标签信息,也就是说所有MQTT Clients必须要知道消息格式。而CoAP协议则相反,因为CoAP内置发现支持和内容协商,这样便能允许设备相互窥测以找到数据交换的方式。 2、MQTT是长连接而CoAP是无连接。MQTT Clients与Broker之间保持TCP长连接,这种情形在NAT环境中也不会产生问题。如果在NAT环境下使用CoAP的话,那就需要采取一些NAT穿透性手段。 3、MQTT是多个客户端通过中央代理进行消息传递的多对多协议。它主要通过让客户端发布消息、代理决定消息路由和复制来解耦消费者和生产者。MQTT就是相当于消息传递的实时通讯总线。CoAP基本上就是一个在Server和Client之间传递状态信息的单对单协议。 HTTP协议http的全称是HyperText Transfer Protocol,超文本传输协议,这个协议的提出就是为了提供和接收HTML界面,通过这个协议在互联网上面传出web的界面信息。 HTTP协议的两个过程,Request和Response,两个都有各自的语言格式,我们看下是什么。请求报文格式:(注意这里有个换行) 响应报文格式:(注意这里有个换行) 方法method:       这个很重要,比如说GET和POST方法,这两个是很常用的,GET就是获取什么内容,而POST就是向服务器发送什么数据。当然还有其他的,比如HTTP 1.1中还有:DELETE、PUT、CONNECT、HEAD、OPTIONS、TRACE等一共8个方法(HTTP Method历史:HTTP 0.9 只有GET方法;HTTP 1.0 有GET、POST、HEAD三个方法)。请求URL:       这里填写的URL是不包含IP地址或者域名的,是主机本地文件对应的目录地址,所以我们一般看到的就是“/”。版本version:       格式是HTTP/.这样的格式,比如说HTTP/1.1.这个版本代表的就是我们使用的HTTP协议的版本,现在使用的一般是HTTP/1.1状态码status:       状态码是三个数字,代表的是请求过程中所发生的情况,比如说200代表的是成功,404代表的是找不到文件。原因短语reason-phrase:       是状态码的可读版本,状态码就是一个数字,如果你事先不知道这个数字什么意思,可以先查看一下原因短语。首部header:       注意这里的header我们不是叫做头,而是叫做首部。可能有零个首部也可能有多个首部,每个首部包含一个名字后面跟着一个冒号,然后是一个可选的空格,接着是一个值,然后换行。实体的主体部分entity-body:       实体的主体部分包含一个任意数据组成的数据块,并不是所有的报文都包含实体的主体部分,有时候只是一个空行加换行就结束了。 下面我们举个简单的例子: 请求报文:GET /index.html HTTP/1.1    Accept: text/*Host: www.myweb.com 响应报文:HTTP/1.1 200 OKContent-type: text/plainContent-length: 3  HTTP与CoAP的区别 CoAP是6LowPAN协议栈中的应用层协议,基于REST(表述性状态传递)架构风格,支持与REST进行交互。通常用户可以像使用HTTP协议一样用CoAP协议来访问物联网设备。而且CoAP消息格式使用简单的二进制格式,最小为4个字节。HTTP使用报文格式对于嵌入式设备来说需要传输数据太多,太重,不够灵活。 XMPP协议 XMPP(可扩展通讯和表示协议)是一种基于可扩展标记语言(XML)的协议, 它继承了在XML环境中灵活的发展性。可用于服务类实时通讯、表示和需求响应服务中的XML数据元流式传输。XMPP以Jabber协议为基础,而Jabber是即时通讯中常用的开放式协议。   基本网络结构 XMPP中定义了三个角色,客户端,服务器,网关。通信能够在这三者的任意两个之间双向发生。 服务器同时承担了客户端信息记录,连接管理和信息的路由功能。网关承担着与异构即时通信系统 的互联互通,异构系统可以包括SMS(短信),MSN,ICQ等。基本的网络形式是单客户端通过 TCP/IP连接到单服务器,然后在之上传输XML。 功能 传输的是与即时通讯相关的指令。在以前这些命令要么用2进制的形式发送(比如QQ),要么用纯文本指令加空格加参数加换行符的方式发送(比如MSN)。而XMPP传输的即时通讯指令的逻辑与以往相仿,只是协议的形式变成了XML格式的纯文本。举个例子看看所谓的XML(标准通用标记语言的子集)流是什么样子的?客户端:123456<?xmlversion='1.0'?>to='example_com'xmlns='jabber:client'xmlns:stream='http_etherx_jabber_org/streams'version='1.0'>服务器:1234567<?xmlversion='1.0'?>from='example_com'id='someid'xmlns='jabber:client'xmlns:stream='http_etherx_jabber_org/streams'version='1.0'>工作原理XMPP核心协议通信的基本模式就是先建立一个stream,然后协商一堆安全之类的东西, 中间通信过程就是客户端发送XML Stanza,一个接一个的。服务器根据客户端发送的信息 以及程序的逻辑,发送XML Stanza给客户端。但是这个过程并不是一问一答的,任何时候 都有可能从一方发信给另外一方。通信的最后阶段是关闭流,关闭TCP/IP连接。  网络通信过程中数据冗余率非常高,网络流量中70% 都消耗在 XMPP 协议层了。对于物联网来说,大量计算能力有限且工作在低带宽、不可靠网络的远程传感器和控制设备,省电、省流量是所有底层服务的一个关键技术指标,XMPP协议看起来已经落后了。 SoAP协议 SoAP(简单对象访问协议)是交换数据的一种协议规范,是一种轻量的、简单的、 基于可扩展标记语言(XML)的协议,它被设计成在WEB上交换结构化的和固化的信息。  SOAP 可以和现存的许多因特网协议和格式结合使用,包括超文本传输协议(HTTP), 简单邮件传输协议(SMTP),多用途网际邮件扩充协议(MIME)。它还支持从消息系统到 远程过程调用(RPC)等大量的应用程序。SOAP使用基于XML的数据结构和超文本传输协议 (HTTP)的组合定义了一个标准的方法来使用Internet上各种不同操作环境中的分布式对象。 总结: 从当前物联网应用发展趋势来分析,MQTT协议具有一定的优势。因为目前国内外主要的云计算服务商,比如阿里云、AWS、百度云、Azure以及腾讯云都一概支持MQTT协议。还有一个原因就是MQTT协议比CoAP成熟的要早,所以MQTT具有一定的先发优势。但随着物联网的智能化和多变化的发展,后续物联网应用平台肯定会兼容更多的物联网应用层协议。 作者:HFK_Frank 来源:CSDN 原文:https://blog.csdn.net/acongge2010/article/details/79142380 版权声明:本文为博主原创文章,转载请附上博文链接!
auto_answer 2019-12-02 01:55:21 0 浏览量 回答数 0

问题

Java开发工程师必备技能

java开发工程师必备技能 操作系统: Windows系统 Linux系统 中间件: Tomcat WebLogic 是一个基于JAVAEE架构的中间件,BEA WebLogic是用于开发、集成、部...
小柒2012 2019-12-01 20:55:20 11780 浏览量 回答数 3

问题

企业级分布式应用服务 EDAS名词含义是什么?

Ali-TomcatAli-Tomcat 是 EDAS 中的服务运行时必须依赖的一个容器,主要集成了服务的发布、订阅、调用链追踪等一系列的核心功能,无论是开发环境还是运行时,均必须将应用程序发布在该...
猫饭先生 2019-12-01 21:03:04 1084 浏览量 回答数 0

回答

IP数据包到路由器之后,它首先要读去IP包头的目标IP地址,然后查看路由表,根据路由协议算法,确定一条最佳的路径,为什么要这样做呢,那是因为要确定这个数据包应该从路由器上的那个接口上转发出去,很明显路由的每一条可用的路由都和路由嚣上的接口是对应的,就这样一个数据包就离开了这个路由器。事情就是这样。看见楼上有一个不太正确的说法,IP数据包头里的源IP和目标IP都不会被改变,如果改变数据包不可能到达或者回来,但只有一种情况,源和目标IP是被改变的,那就是NAT.路由器转发数据包不会对它的IP源地址和目标地址做修改,只会修改MAC.具体路由器转发规则如下:当主机A发向主机B的数据流在网络层封装成IP数据包,IP数据包的首部包含了源地址和目标地址。主机A会用本机配置的24位IP网络掩码255.255.255.0与目标地址进行与运算,得出目标网络地址与本机的网络地址是不是在同一个网段中。如果不是将IP数据包转发到网关。在发往网关前主机A还会通过ARP的请求获得默认网关的MAC地址。在主机A数据链路层IP数据包封装成以太网数据帧,然后才发住到网关……也就是路由器上的一个端口。当网关路由器接收到以太网数据帧时,发现数据帧中的目标MAC地址是自己的某一个端口的物理地址,这时路由器会把以太网数据帧的封装去掉。路由器认为这个IP数据包是要通过自己进行转发,接着它就在匹配路由表。匹配到路由项后,它就将包发往下一条地址。路由器转发数据包就是这样,所以它始终是不会改IP地址的。只会改MAC.当有数据包传到路由器时,路由器首先将其的目的地址与路由表进行对比,如果是本地网络,将不会进行转发到外网络,而是直接转发给本地网内的目的主机,改变的只是数据包的源地址,(原源地址MAC变为了路由器的MAC);当然其中的过程关系到相关的协议的使用,像什么ARP,IP等。但是如果目的地址经路由表对比,发现不是在本网中,有nat就将改变源地址的IP(原源地址的Ip地址改为了路由器的IP地址),路由器将熟数据包转发到相应的端口,进行通信。如:A访问B,首先对比是否同一子网,如果是,检查ARP表,有B的MAC就直接发送,没有就发送ARP请求.如果否,发送到默认网关C,源IP为A,源MAC为A,目的IP为B,目的MAC地址为C,C接收到这个包,检查路由表,发送到下一跳D,源IP为A,源MAC为C,目的IP为B,目的MAC为D.....如此循环,直到发送到B.NAT为特殊应用,会修改源IP为网关自己外网IP。
青蛙跳 2019-12-02 00:22:43 0 浏览量 回答数 0

回答

.推送方式基础知识:当我们开发需要和服务器交互的应用程序时,基本上都需要获取服务器端的数据,比如《地震应急通》就需要及时获取服务器上最新的地震信息。要获取服务器 上不定时更新的信息一般来说有两种方法,第一种是客户端使用Pull(拉)的方式,隔一段时间就去服务器上获取信息,看是否有更新的信息出现。第二种就是 服务器使用Push(推送)的方式,当服务器端有新信息了,则把最新的信息Push到客户端上。 虽然Pull和Push两种方式都能实现获取服务器端更新信息的功能,但是明显来说Push is better than pull。因为Pull方式更费客户端的网络流量,更主要的是费电量。  在开发Android和iPhone应用程序时,我们往往需要从服务器不定的向手机客户端即时推送各种通知消息,iPhone上已经有了比较简单的和完美的推送通知解决方案,我会在以后详细介绍IPhone中的解决方案,可是Android平台上实现起来却相对比较麻烦,最近利用几天的时间对Android的推送通知服务进行初步的研究。 在Android手机平台上,Google提供了C2DM(Cloudto Device Messaging)服务,起初我就是准备采用这个服务来实现自己手机上的推送功能。  Android Cloud to Device Messaging (C2DM)是一个用来帮助开发者从服务器向Android应用程序发送数据的服务。该服务提供了一个简单的、轻量级的机制,允许服务器可以通知移动应用程序直接与服务器进行通信,以便于从服务器获取应用程序更新和用户数据。C2DM服务负责处理诸如消息排队等事务并向运行于目标设备上的应用程序分发这些消息。关于C2DM具体使用过程,我会以后的博文中再详细介绍,这里大家先了解下大致方案情况。C2DM操作过程图:但是经过一番研究发现,这个服务存在很大的问题:1)C2DM内置于Android的2.2系统上,无法兼容老的1.6到2.1系统;2)C2DM需要依赖于Google官方提供的C2DM服务器,由于国内的网络环境,这个服务经常不可用,如果想要很好的使用,我们的App Server必须也在国外,这个恐怕不是每个开发者都能够实现的; 有了上述两个使用上的制约,导致我最终放弃了这个方案,不过我想利用另外一篇文章来详细的介绍C2DM的框架以及客户端和App Server的相应设置方法,可以作为学习与参考之用。 即然C2DM无法满足我们的要求,那么我们就需要自己来实现Android手机客户端与App Server之间的通信协议,保证在App Server想向指定的Android设备发送消息时,Android设备能够及时的收到。几种常见的解决方案1)轮询(Pull):应用程序应当阶段性的与服务器进行连接并查询是否有新的消息到达,你必须自己实现与服务器之间的通信,例如消息排队等。而且你还要考虑轮询的频率,如果太慢可能导致某些消息的延迟,如果太快,则会大量消耗网络带宽和电池。2)SMS(Push):在Android平台上,你可以通过拦截SMS消息并且解析消息内容来了解服务器的意图。这是一个不错的想法,我就见过采 用这个方案的应用程序。这个方案的好处是,可以实现完全的实时操作。但是问题是这个方案的成本相对比较高,你很难找到免费的短消息发送网关,关于这个方案的实现。3)持久连接(Push):这个方案可以解决由轮询带来的性能问题,但是还是会消耗手机的电池。Apple的推送服务之所以工作的很好,是因为每一 台手机仅仅保持一个与服务器之间的连接,事实上C2DM也是这么工作的。不过这个方案也存在不足,就是我们很难在手机上实现一个可靠的服务。Android操作系统允许在低内存情况下杀死系统服务,所以你的通知服务很可能被操作系统Kill掉了。 前两个方案存在明显的不足,第三个方案也有不足,不过我们可以通过良好的设计来弥补,以便于让该方案可以有效的工作。毕竟,我们要知道GMail,GTalk以及GoogleVoice都可以实现实时更新的。MQTT协议实现Android推送采用MQTT协议实现Android推送 MQTT是一个轻量级的消息发布/订阅协议,它是实现基于手机客户端的消息推送服务器的理想解决方案。 wmqtt.jar 是IBM提供的MQTT协议的实现。我们可以从这里下载该项目的实例代码,并且可以找到一个采用PHP书写的服务器端实现。架构如下所示:wmqtt.jar 是IBM提供的MQTT协议的实现。我们可以从如下站点下载它。你可以将该jar包加入你自己的Android应用程序中。4.RSMB实现推送:Really Small Message Broker (RSMB) ,他是一个简单的MQTT代理,同样由IBM提供。缺省打开1883端口,应用程序当中,它负责接收来自服务器的消息并将其转发给指定的移动设备。SAM是一个针对MQTT写的PHP库。我们可以从这个下载它.send_mqtt.php是一个通过POST接收消息并且通过SAM将消息发送给RSMB的PHP脚本。Really Small Message Broker (RSMB) ,他是一个简单的MQTT代理,同样由IBM提供。缺省打开1883端口,应用程序当中,它负责接收来自服务器的消息并将其转发给指定的移动设备。XMPP协议实现Android推送这是我在项目中采用的方案。事实上Google官方的C2DM服务器底层也是采用XMPP协议进行的封装。 XMPP(可扩展通讯和表示协议)是基于可扩展标记语言(XML)的协议,它用于即时消息(IM)以及在线探测。这个协议可能最终允许因特网用户向因特网上的其他任何人发送即时消息。关于XMPP协议我在上篇博文中已经介绍,大家可以参考:http://www.cnblogs.com/hanyonglu/archive/2012/03/04/2378956.htmlandroidpn是一个基于XMPP协议的java开源Android push notification实现,我会在以后的博文中详细介绍androidpn。它包含了完整的客户端和服务器端。经过源代码研究我发现,该服务器端基本是在另外一个开源工程openfire基础上修改实现的,不过比较郁闷的是androidpn的文档是由韩语写的,所以整个研究过程基本都是读源码。实现意图如下图所示:androidpn 客户端需要用到一个基于java的开源XMPP协议包asmack,这个包同样也是基于openfire下的另外一个开源项目smack,不过我们不需要 自己编译,可以直接把androidpn客户端里面的asmack.jar拿来使用。客户端利用asmack中提供的XMPPConnection类与服 务器建立持久连接,并通过该连接进行用户注册和登录认证,同样也是通过这条连接,接收服务器发送的通知。androidpn服务器端也是java语言实现的,基于openfire开源工程,不过它的Web部分采用的是spring框架,这一点与 openfire是不同的。Androidpn服务器包含两个部分,一个是侦听在5222端口上的XMPP服务,负责与客户端的 XMPPConnection类进行通信,作用是用户注册和身份认证,并发送推送通知消息。另外一部分是Web服务器,采用一个轻量级的HTTP服务器, 负责接收用户的Web请求。服务器架构如下:最上层包含四个组成部分,分别是SessionManager,Auth Manager,PresenceManager以及Notification Manager。SessionManager负责管理客户端与服务器之间的会话,Auth Manager负责客户端用户认证管理,Presence Manager负责管理客户端用户的登录状态,NotificationManager负责实现服务器向客户端推送消息功能。这个解决方案的最大优势就是简单,我们不需要象C2DM那样依赖操作系统版本,也不会担心某一天Google服务器不可用。利用XMPP协议我们还可以进一步的对协议进行扩展,实现更为完善的功能。 采用这个方案,我们目前只能发送文字消息,不过对于推送来说一般足够了,因为我们不能指望通过推送得到所有的数据,一般情况下,利用推送只是告诉手机端服务器发生了某些改变,当客户端收到通知以后,应该主动到服务器获取最新的数据,这样才是推送服务的完整实现。作者:qq_594336505 来源:CSDN 原文:https://blog.csdn.net/qq_23174861/article/details/51730760 版权声明:本文为博主原创文章,转载请附上博文链接!
auto_answer 2019-12-02 01:48:09 0 浏览量 回答数 0

问题

如何更优雅的使用VPC专有网络

经常有刚起步的站长和开发者问我,私有网络和公有网络区别是什么?在阿里云上面有没有公有网络、私有网络?而阿里云对网络的命名又分为经典网络、和VPC专有网络,所以不少小伙伴看晕了。我们这次...
李博 bluemind 2019-12-01 21:57:12 3256 浏览量 回答数 1

问题

如何更优雅的使用VPC专有网络

经常有刚起步的站长和开发者问我,私有网络和公有网络区别是什么?在阿里云上面有没有公有网络、私有网络?而阿里云对网络的命名又分为经典网络、和VPC专有网络,所以不少小伙伴看晕了。我们这次...
李博 bluemind 2019-12-01 21:57:11 3369 浏览量 回答数 0

问题

100%移植阿里云移动测试技术,竟仅需1周?! ——移动测试专有云(1)

移动设备大量涌现,终端类型浩如烟海,任何一款设备的兼容性问题都将导致大量用户流失 ! 移动终端的配置千差万别,碎片化严重又导致APP的全机型适配成本巨大且异常困难 ! ...
mqc 2019-12-01 21:11:15 1796 浏览量 回答数 0

问题

阿里云中间件是什么

很多人搞不懂中间件是什么。中间件是一种处于操作系统(底层)和应用之间的软件或者组件,起到让应用在操作系统上可以正常运行的作用,向apache,iis,sqlserver等。 阿里云正在...
搞么罗 2019-12-01 21:51:58 1418 浏览量 回答数 0

回答

Lease 机制是最重要的分布式协议,广泛应用于各种实际的分布式系统中。 基于lease 的分布式cache 系统 基本的问题背景如下:在一个分布式系统中,有一个中心服务器节点,中心服务器存储、维护 着一些数据,这些数据是系统的元数据。系统中其他的节点通过访问中心服务器节点读取、修改其 上的元数据。由于系统中各种操作都依赖于元数据,如果每次读取元数据的操作都访问中心服务器 节点,那么中心服务器节点的性能成为系统的瓶颈。为此,设计一种元数据cache,在各个节点上 cache 元数据信息,从而减少对中心服务器节点的访问,提高性能。另一方面,系统的正确运行严 格依赖于元数据的正确,这就要求各个节点上cache 的数据始终与中心服务器上的数据一致,cache 中的数据不能是旧的脏数据。最后,设计的cache 系统要能最大可能的处理节点宕机、网络中断等 异常,最大程度的提高系统的可用性。 为此,利用lease 机制设计一套cache 系统,其基本原理为如下。中心服务器在向各节点发送数 据时同时向节点颁发一个lease。每个lease 具有一个有效期,和信用卡上的有效期类似,lease 上的 有效期通常是一个明确的时间点,例如12:00:10,一旦真实时间超过这个时间点,则lease 过期失效。 这样lease 的有效期与节点收到lease 的时间无关,节点可能收到lease 时该lease 就已经过期失效。 这里首先假设中心服务器与各节点的时钟是同步的,下节中讨论时钟不同步对lease 的影响。中心服 务器发出的lease 的含义为:在lease 的有效期内,中心服务器保证不会修改对应数据的值。因此, 节点收到数据和lease 后,将数据加入本地Cache,一旦对应的lease 超时,节点将对应的本地cache 数据删除。中心服务器在修改数据时,首先阻塞所有新的读请求,并等待之前为该数据发出的所有 lease 超时过期,然后修改数据的值。 基于lease 的cache,客户端节点读取元数据 判断元数据是否已经处于本地cache 且lease 处于有效期内 1.1 是:直接返回cache 中的元数据 1.2 否:向中心服务器节点请求读取元数据信息 1.2.1 服务器收到读取请求后,返回元数据及一个对应的lease 1.2.2 客户端是否成功收到服务器返回的数据 1.2.2.1 失败或超时:退出流程,读取失败,可重试 1.2.2.2 成功:将元数据与该元数据的lease 记录到内存中,返回元数据 基于lease 的cache,客户端节点修改元数据流程 2.1 节点向服务器发起修改元数据请求。 2.2 服务器收到修改请求后,阻塞所有新的读数据请求,即接收读请求,但不返回数据。 2.3 服务器等待所有与该元数据相关的lease 超时。 2.4 服务器修改元数据并向客户端节点返回修改成功。 上述机制可以保证各个节点上的cache 与中心服务器上的中心始终一致。这是因为中心服务器 节点在发送数据的同时授予了节点对应的lease,在lease 有效期内,服务器不会修改数据,从而客 户端节点可以放心的在lease 有效期内cache 数据。上述lease 机制可以容错的关键是:服务器一旦 发出数据及lease,无论客户端是否收到,也无论后续客户端是否宕机,也无论后续网络是否正常, 服务器只要等待lease 超时,就可以保证对应的客户端节点不会再继续cache 数据,从而可以放心的 修改数据而不会破坏cache 的一致性。 上述基础流程有一些性能和可用性上的问题,但可以很容易就优化改性。优化点一:服务器在 修改元数据时首先要阻塞所有新的读请求,造成没有读服务。这是为了防止发出新的lease 从而引起 不断有新客户端节点持有lease 并缓存着数据,形成“活锁”。优化的方法很简单,服务器在进入修 改数据流程后,一旦收到读请求则只返回数据但不颁发lease。从而造成在修改流程执行的过程中, 客户端可以读到元数据,只是不能缓存元数据。进一步的优化是,当进入修改流程,服务器颁发的 lease 有效期限选择为已发出的lease 的最大有效期限。这样做,客户端可以继续在服务器进入修改 流程后继续缓存元数据,但服务器的等待所有lease 过期的时间也不会因为颁发新的lease 而不断延 长。 最后,=cache 机制与多副本机制的区别。Cache 机制与多副本机制的相似之处都 是将一份数据保存在多个节点上。但Cache 机制却要简单许多,对于cache 的数据,可以随时删除 丢弃,并命中cache 的后果仅仅是需要访问数据源读取数据;然而副本机制却不一样,副本是不能 随意丢弃的,每失去一个副本,服务质量都在下降,一旦副本数下降到一定程度,则往往服务将不 再可用。 lease 机制的分析 lease 的定义:Lease 是由颁发者授予的在某一有效期内的承诺。颁发者一旦发 出lease,则无论接受方是否收到,也无论后续接收方处于何种状态,只要lease 不过期,颁发者一 定严守承诺;另一方面,接收方在lease 的有效期内可以使用颁发者的承诺,但一旦lease 过期,接 收方一定不能继续使用颁发者的承诺。 Lease 机制具有很高的容错能力。首先,通过引入有效期,Lease 机制能否非常好的容错网络异 常。Lease 颁发过程只依赖于网络可以单向通信,即使接收方无法向颁发者发送消息,也不影响lease 的颁发。由于lease 的有效期是一个确定的时间点,lease 的语义与发送lease 的具体时间无关,所以 同一个lease 可以被颁发者不断重复向接受方发送。即使颁发者偶尔发送lease 失败,颁发者也可以 简单的通过重发的办法解决。一旦lease 被接收方成功接受,后续lease 机制不再依赖于网络通信, 即使网络完全中断lease 机制也不受影响。再者,Lease 机制能较好的容错节点宕机。如果颁发者宕 机,则宕机的颁发者通常无法改变之前的承诺,不会影响lease 的正确性。在颁发者机恢复后,如果 颁发者恢复出了之前的lease 信息,颁发者可以继续遵守lease 的承诺。如果颁发者无法恢复lease 信息,则只需等待一个最大的lease 超时时间就可以使得所有的lease 都失效,从而不破坏lease 机制。 例如上节中的cache 系统的例子中,一旦服务器宕机,肯定不会修改元数据,重新恢复后,只需等 待一个最大的lease 超时时间,所有节点上的缓存信息都将被清空。对于接受方宕机的情况,颁发者 不需要做更多的容错处理,只需等待lease 过期失效,就可以收回承诺,实践中也就是收回之前赋予 的权限、身份等。最后,lease 机制不依赖于存储。颁发者可以持久化颁发过的lease 信息,从而在 宕机恢复后可以使得在有效期的lease 继续有效。但这对于lease 机制只是一个优化,如之前的分析, 即使颁发者没有持久化lease 信息,也可以通过等待一个最大的lease 时间的方式使得之前所有颁发 的lease 失效,从而保证机制继续有效。 Lease 机制依赖于有效期,这就要求颁发者和接收者的时钟是同步的。一方面,如果颁发者的 时钟比接收者的时钟慢,则当接收者认为lease 已经过期的时候,颁发者依旧认为lease 有效。接收 者可以用在lease 到期前申请新的lease 的方式解决这个问题。另一方面,如果颁发者的时钟比接收 者的时钟快,则当颁发者认为lease 已经过期的时候,接收者依旧认为lease 有效,颁发者可能将lease 颁发给其他节点,造成承诺失效,影响系统的正确性。对于这种时钟不同步,实践中的通常做法是 将颁发者的有效期设置得比接收者的略大,只需大过时钟误差就可以避免对lease 的有效性的影响。 基于lease 机制确定节点状态 分布式协议依赖于对节点状态认知的全局一致性,即一旦节点Q 认为某个节点 A 异常,则节点A 也必须认为自己异常,从而节点A 停止作为primary,避免“双主”问题的出现。 解决这种问题有两种思路,第一、设计的分布式协议可以容忍“双主”错误,即不依赖于对节点状 态的全局一致性认识,或者全局一致性状态是全体协商后的结果;第二、利用lease 机制。对于第一 种思路即放弃使用中心化的设计,而改用去中心化设计,超过本节的讨论范畴。下面着重讨论利用 lease 机制确定节点状态。 由中心节点向其他节点发送lease,若某个节点持有有效的lease,则认为该节点正常可以提供服 务。用于例2.3.1 中,节点A、B、C 依然周期性的发送heart beat 报告自身状态,节点Q 收到heart beat 后发送一个lease,表示节点Q 确认了节点A、B、C 的状态,并允许节点在lease 有效期内正常工 作。节点Q 可以给primary 节点一个特殊的lease,表示节点可以作为primary 工作。一旦节点Q 希 望切换新的primary,则只需等前一个primary 的lease 过期,则就可以安全的颁发新的lease 给新的 primary 节点,而不会出现“双主”问题。 在实际系统中,若用一个中心节点发送lease 也有很大的风险,一旦该中心节点宕机或网络异常, 则所有的节点没有lease,从而造成系统高度不可用。为此,实际系统总是使用多个中心节点互为副 本,成为一个小的集群,该小集群具有高可用性,对外提供颁发lease 的功能。chubby 和zookeeper 都是基于这样的设计。 lease 的有效期时间选择 工程中,常选择的lease 时长是10 秒级别,这是一个经 过验证的经验值,实践中可以作为参考并综合选择合适的时长。
kun坤 2020-04-24 15:31:41 0 浏览量 回答数 0

问题

Spring Cloud Alibaba:Spring 社区的唯一国产开源项目

Spring Cloud Alibaba现已升级到2.1.0。Spring Cloud Alibaba为分布式应用程序开发提供了一站式解决方案。它包含开发分布式应用程序所需的所有组件,使您可以轻松地使用Spring Cloud...
珍宝珠 2020-02-17 17:19:23 211 浏览量 回答数 1

问题

企业级分布式应用服务 EDAS应用场景一般在哪里?

应用发布与管理 在云环境中,应用发布与管理会变得十分复杂。本地开发完成的应用需要登录到每一台服务器进行发布和部署;后续还会有应用的重启,扩容等。服务器的不断增加对于运维人员将是一个极大的挑战。 ...
猫饭先生 2019-12-01 21:03:04 1064 浏览量 回答数 0

回答

在工程实践上,为了保障系统的可用性,互联网系统大多将强一致性需求转换成最终一致性的需求,并通过系统执行幂等性的保证,保证数据的最终一致性。但在电商等场景中,对于数据一致性的解决方法和常见的互联网系统(如 MySQL 主从同步)又有一定区别,分成以下 6 种解决方案。(一)规避分布式事务——业务整合业务整合方案主要采用将接口整合到本地执行的方法。拿问题场景来说,则可以将服务 A、B、C 整合为一个服务 D 给业务,这个服务 D 再通过转换为本地事务的方式,比如服务 D 包含本地服务和服务 E,而服务 E 是本地服务 A ~ C 的整合。优点:解决(规避)了分布式事务。缺点:显而易见,把本来规划拆分好的业务,又耦合到了一起,业务职责不清晰,不利于维护。由于这个方法存在明显缺点,通常不建议使用。(二)经典方案 - eBay 模式此方案的核心是将需要分布式处理的任务通过消息日志的方式来异步执行。消息日志可以存储到本地文本、数据库或消息队列,再通过业务规则自动或人工发起重试。人工重试更多的是应用于支付场景,通过对账系统对事后问题的处理。消息日志方案的核心是保证服务接口的幂等性。考虑到网络通讯失败、数据丢包等原因,如果接口不能保证幂等性,数据的唯一性将很难保证。eBay 方式的主要思路如下。Base:一种 Acid 的替代方案此方案是 eBay 的架构师 Dan Pritchett 在 2008 年发表给 ACM 的文章,是一篇解释 BASE 原则,或者说最终一致性的经典文章。文中讨论了 BASE 与 ACID 原则在保证数据一致性的基本差异。如果 ACID 为分区的数据库提供一致性的选择,那么如何实现可用性呢?答案是BASE (basically available, soft state, eventually consistent)BASE 的可用性是通过支持局部故障而不是系统全局故障来实现的。下面是一个简单的例子:如果将用户分区在 5 个数据库服务器上,BASE 设计鼓励类似的处理方式,一个用户数据库的故障只影响这台特定主机那 20% 的用户。这里不涉及任何魔法,不过它确实可以带来更高的可感知的系统可用性。文章中描述了一个最常见的场景,如果产生了一笔交易,需要在交易表增加记录,同时还要修改用户表的金额。这两个表属于不同的远程服务,所以就涉及到分布式事务一致性的问题。文中提出了一个经典的解决方法,将主要修改操作以及更新用户表的消息放在一个本地事务来完成。同时为了避免重复消费用户表消息带来的问题,达到多次重试的幂等性,增加一个更新记录表 updates_applied 来记录已经处理过的消息。基于以上方法,在第一阶段,通过本地的数据库的事务保障,增加了 transaction 表及消息队列 。在第二阶段,分别读出消息队列(但不删除),通过判断更新记录表 updates_applied 来检测相关记录是否被执行,未被执行的记录会修改 user 表,然后增加一条操作记录到 updates_applied,事务执行成功之后再删除队列。通过以上方法,达到了分布式系统的最终一致性。进一步了解 eBay 的方案可以参考文末链接。(三)去哪儿网分布式事务方案随着业务规模不断地扩大,电商网站一般都要面临拆分之路。就是将原来一个单体应用拆分成多个不同职责的子系统。比如以前可能将面向用户、客户和运营的功能都放在一个系统里,现在拆分为订单中心、代理商管理、运营系统、报价中心、库存管理等多个子系统。拆分首先要面临的是什么呢?最开始的单体应用所有功能都在一起,存储也在一起。比如运营要取消某个订单,那直接去更新订单表状态,然后更新库存表就 ok 了。因为是单体应用,库在一起,这些都可以在一个事务里,由关系数据库来保证一致性。但拆分之后就不同了,不同的子系统都有自己的存储。比如订单中心就只管理自己的订单库,而库存管理也有自己的库。那么运营系统取消订单的时候就是通过接口调用等方式来调用订单中心和库存管理的服务了,而不是直接去操作库。这就涉及一个『分布式事务』的问题。分布式事务有两种解决方式优先使用异步消息。上文已经说过,使用异步消息 Consumer 端需要实现幂等。幂等有两种方式,一种方式是业务逻辑保证幂等。比如接到支付成功的消息订单状态变成支付完成,如果当前状态是支付完成,则再收到一个支付成功的消息则说明消息重复了,直接作为消息成功处理。另外一种方式如果业务逻辑无法保证幂等,则要增加一个去重表或者类似的实现。对于 producer 端在业务数据库的同实例上放一个消息库,发消息和业务操作在同一个本地事务里。发消息的时候消息并不立即发出,而是向消息库插入一条消息记录,然后在事务提交的时候再异步将消息发出,发送消息如果成功则将消息库里的消息删除,如果遇到消息队列服务异常或网络问题,消息没有成功发出那么消息就留在这里了,会有另外一个服务不断地将这些消息扫出重新发送。有的业务不适合异步消息的方式,事务的各个参与方都需要同步的得到结果。这种情况的实现方式其实和上面类似,每个参与方的本地业务库的同实例上面放一个事务记录库。比如 A 同步调用 B,C。A 本地事务成功的时候更新本地事务记录状态,B 和 C 同样。如果有一次 A 调用 B 失败了,这个失败可能是 B 真的失败了,也可能是调用超时,实际 B 成功。则由一个中心服务对比三方的事务记录表,做一个最终决定。假设现在三方的事务记录是 A 成功,B 失败,C 成功。那么最终决定有两种方式,根据具体场景:重试 B,直到 B 成功,事务记录表里记录了各项调用参数等信息;执行 A 和 B 的补偿操作(一种可行的补偿方式是回滚)。对 b 场景做一个特殊说明:比如 B 是扣库存服务,在第一次调用的时候因为某种原因失败了,但是重试的时候库存已经变为 0,无法重试成功,这个时候只有回滚 A 和 C 了。那么可能有人觉得在业务库的同实例里放消息库或事务记录库,会对业务侵入,业务还要关心这个库,是否一个合理的设计?实际上可以依靠运维的手段来简化开发的侵入,我们的方法是让 DBA 在公司所有 MySQL 实例上预初始化这个库,通过框架层(消息的客户端或事务 RPC 框架)透明的在背后操作这个库,业务开发人员只需要关心自己的业务逻辑,不需要直接访问这个库。总结起来,其实两种方式的根本原理是类似的,也就是将分布式事务转换为多个本地事务,然后依靠重试等方式达到最终一致性。(四)蘑菇街交易创建过程中的分布式一致性方案交易创建的一般性流程我们把交易创建流程抽象出一系列可扩展的功能点,每个功能点都可以有多个实现(具体的实现之间有组合/互斥关系)。把各个功能点按照一定流程串起来,就完成了交易创建的过程。面临的问题每个功能点的实现都可能会依赖外部服务。那么如何保证各个服务之间的数据是一致的呢?比如锁定优惠券服务调用超时了,不能确定到底有没有锁券成功,该如何处理?再比如锁券成功了,但是扣减库存失败了,该如何处理?方案选型服务依赖过多,会带来管理复杂性增加和稳定性风险增大的问题。试想如果我们强依赖 10 个服务,9 个都执行成功了,最后一个执行失败了,那么是不是前面 9 个都要回滚掉?这个成本还是非常高的。所以在拆分大的流程为多个小的本地事务的前提下,对于非实时、非强一致性的关联业务写入,在本地事务执行成功后,我们选择发消息通知、关联事务异步化执行的方案。消息通知往往不能保证 100% 成功;且消息通知后,接收方业务是否能执行成功还是未知数。前者问题可以通过重试解决;后者可以选用事务消息来保证。但是事务消息框架本身会给业务代码带来侵入性和复杂性,所以我们选择基于 DB 事件变化通知到 MQ 的方式做系统间解耦,通过订阅方消费 MQ 消息时的 ACK 机制,保证消息一定消费成功,达到最终一致性。由于消息可能会被重发,消息订阅方业务逻辑处理要做好幂等保证。所以目前只剩下需要实时同步做、有强一致性要求的业务场景了。在交易创建过程中,锁券和扣减库存是这样的两个典型场景。要保证多个系统间数据一致,乍一看,必须要引入分布式事务框架才能解决。但引入非常重的类似二阶段提交分布式事务框架会带来复杂性的急剧上升;在电商领域,绝对的强一致是过于理想化的,我们可以选择准实时的最终一致性。我们在交易创建流程中,首先创建一个不可见订单,然后在同步调用锁券和扣减库存时,针对调用异常(失败或者超时),发出废单消息到MQ。如果消息发送失败,本地会做时间阶梯式的异步重试;优惠券系统和库存系统收到消息后,会进行判断是否需要做业务回滚,这样就准实时地保证了多个本地事务的最终一致性。(五)支付宝及蚂蚁金融云的分布式服务 DTS 方案业界常用的还有支付宝的一种 xts 方案,由支付宝在 2PC 的基础上改进而来。主要思路如下,大部分信息引用自官方网站。分布式事务服务简介分布式事务服务 (Distributed Transaction Service, DTS) 是一个分布式事务框架,用来保障在大规模分布式环境下事务的最终一致性。DTS 从架构上分为 xts-client 和 xts-server 两部分,前者是一个嵌入客户端应用的 JAR 包,主要负责事务数据的写入和处理;后者是一个独立的系统,主要负责异常事务的恢复。核心特性传统关系型数据库的事务模型必须遵守 ACID 原则。在单数据库模式下,ACID 模型能有效保障数据的完整性,但是在大规模分布式环境下,一个业务往往会跨越多个数据库,如何保证这多个数据库之间的数据一致性,需要其他行之有效的策略。在 JavaEE 规范中使用 2PC (2 Phase Commit, 两阶段提交) 来处理跨 DB 环境下的事务问题,但是 2PC 是反可伸缩模式,也就是说,在事务处理过程中,参与者需要一直持有资源直到整个分布式事务结束。这样,当业务规模达到千万级以上时,2PC 的局限性就越来越明显,系统可伸缩性会变得很差。基于此,我们采用 BASE 的思想实现了一套类似 2PC 的分布式事务方案,这就是 DTS。DTS在充分保障分布式环境下高可用性、高可靠性的同时兼顾数据一致性的要求,其最大的特点是保证数据最终一致 (Eventually consistent)。简单的说,DTS 框架有如下特性:最终一致:事务处理过程中,会有短暂不一致的情况,但通过恢复系统,可以让事务的数据达到最终一致的目标。协议简单:DTS 定义了类似 2PC 的标准两阶段接口,业务系统只需要实现对应的接口就可以使用 DTS 的事务功能。与 RPC 服务协议无关:在 SOA 架构下,一个或多个 DB 操作往往被包装成一个一个的 Service,Service 与 Service 之间通过 RPC 协议通信。DTS 框架构建在 SOA 架构上,与底层协议无关。与底层事务实现无关: DTS 是一个抽象的基于 Service 层的概念,与底层事务实现无关,也就是说在 DTS 的范围内,无论是关系型数据库 MySQL,Oracle,还是 KV 存储 MemCache,或者列存数据库 HBase,只要将对其的操作包装成 DTS 的参与者,就可以接入到 DTS 事务范围内。一个完整的业务活动由一个主业务服务与若干从业务服务组成。主业务服务负责发起并完成整个业务活动。从业务服务提供 TCC 型业务操作。业务活动管理器控制业务活动的一致性,它登记业务活动中的操作,并在活动提交时确认所有的两阶段事务的 confirm 操作,在业务活动取消时调用所有两阶段事务的 cancel 操作。”与 2PC 协议比较,没有单独的 Prepare 阶段,降低协议成本。系统故障容忍度高,恢复简单(六)农信网数据一致性方案电商业务公司的支付部门,通过接入其它第三方支付系统来提供支付服务给业务部门,支付服务是一个基于 Dubbo 的 RPC 服务。对于业务部门来说,电商部门的订单支付,需要调用支付平台的支付接口来处理订单;同时需要调用积分中心的接口,按照业务规则,给用户增加积分。从业务规则上需要同时保证业务数据的实时性和一致性,也就是支付成功必须加积分。我们采用的方式是同步调用,首先处理本地事务业务。考虑到积分业务比较单一且业务影响低于支付,由积分平台提供增加与回撤接口。具体的流程是先调用积分平台增加用户积分,再调用支付平台进行支付处理,如果处理失败,catch 方法调用积分平台的回撤方法,将本次处理的积分订单回撤。用户信息变更公司的用户信息,统一由用户中心维护,而用户信息的变更需要同步给各业务子系统,业务子系统再根据变更内容,处理各自业务。用户中心作为 MQ 的 producer,添加通知给 MQ。APP Server 订阅该消息,同步本地数据信息,再处理相关业务比如 APP 退出下线等。我们采用异步消息通知机制,目前主要使用 ActiveMQ,基于 Virtual Topic 的订阅方式,保证单个业务集群订阅的单次消费。总结分布式服务对衍生的配套系统要求比较多,特别是我们基于消息、日志的最终一致性方案,需要考虑消息的积压、消费情况、监控、报警等。
小川游鱼 2019-12-02 01:46:40 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 注意:无法打开网站时,应该先搜索排查报错提示的含义,本文列举了一些常见的报错情况。 无法访问 ECS 实例上的网站时的分析思路: 根据报错情况分析网络通信问题 ECS Linux 实例网络通信问题排查ECS Windows 实例网络通信问题排查 端口通信问题 ECS Linux 实例端口通信问题ECS Windows 实例端口通信问题 防火墙配置异常 ECS Windows 实例远程无法连接,关闭防火墙后连接恢复正常ECS Linux 实例 SSH 无法连接,关闭 Iptables 后连接恢复正常 重新配置安全组公网规则 网络通信问题 ECS Linux 实例网络通信问题排查 执行 ifconfig 和 ip addr 网络检测命令查看 IP 地址。 执行命令 route -n 通过实例路由表查看网关。 ECS Windows 实例网络通信问题排查 打开 CMD,执行 ipconfig 网络检测命令查看 IP 地址。 执行命令 route print 通过实例路由表查看网关。 注意: 若网卡驱动未开启或网卡配置有问题,请检查网卡驱动,并重新安装。 关于网络相关问题的测试工具,详见 ping 丢包或不通时链路测试说明。 端口通信问题 ECS Linux 实例端口通信问题 执行命令 netstat –antpu | grep sshd 检测 sshd 服务的运行状态,确认端口是否有正常监听。 执行下列命令查看服务运行状态: CentOS6:service sshd statusCentOS7:systemctl status sshd 如果 sshd 服务没有正常运行,执行下列命令手动启动 sshd 服务: CentOS6:service sshd restartCentOS7:systemctl restart sshd 查看 sshd 程序日志 如果无法正常启动 sshd 服务,CentOS 6 系统一般会直接输出错误信息,而CentOS 7 启动时没有输出信息,需要通过 secure 日志进行查看。sshd 日志:/var/log/secure。 通过 secure 日志的报错信息,一般是可以定位绝大部分 sshd 启动异常的问题。 ECS Windows 实例端口通信问题 执行远程端口检测命令: Tasklist /svc | findstr “Ter”netstat –ano | findstr “$PID” 防火墙配置异常 ECS Windows 实例远程无法连接,关闭防火墙后连接恢复正常 前提条件:您只有在已授权可关闭防火墙的情况下,才能做该项排查。 调整防火墙配置策略,详见:ECS Windows 远程连接之防火墙设置。 调整后,重新进行远程连接。 ECS Linux 实例 SSH 无法连接,关闭 Iptables 后连接恢复正常 前提条件:您只有在已授权可关闭 Iptables 的情况下,才能做调整 Iptables 配置策略排查。 执行命令 iptables -nvL –line-number 查看防火墙规则: n 不对 IP 地址进行反查,加上这个参数显示速度会快很多。 v 输出详细信息,包含通过该规则的数据包数量、总字节数及相应的网络接口。 L 查看当前表的所有规则,默认查看的是 filter 表,如果要查看 NAT 表,可以加上 -t NAT 参数。 修改规则。(若您之前已设置过规则策略,执行命令 cp -a /etc/sysconfig/iptables /etc/sysconfig/iptables.bak 保存一份原有的 Iptables 文件,避免丢失已设置过策略。) 执行命令 iptables -F 清空实例上所有的规则。 执行命令 iptables -P INPUT DROP 拒绝 INPUT 方向所有的请求都。 注意:线上业务请勿直接操作,会导致业务直接中断。 执行下列命令放行端口 22: iptables -A INPUT -p tcp --dport 22 -j ACCEPTiptables -A OUTPUT -p tcp --sport 22 -j ACCEPT执行下列命令指定 IP 访问端口 22: iptables -I INPUT -s 192.168.1.1 -p tcp --dport 22 -j ACCEPT 说明: 192.168.1.1 为请求端 IP 地址。 执行命令 iptables -L 查看添加的规则是否生效。 执行命令 iptables-save > /etc/sysconfig/iptables 保存添加的规则。 执行命令 service iptables restart 或 /etc/init.d/iptables restart 重启 Iptables。 执行命令 systemctl reboot 重启实例验证配置。 重新进行 SSH 连接。 重新配置安全组公网规则 原因分析:安全组默认没有放行网站使用的端口(如 80 端口)。您需要自行放行该接口。 解决方法: 登录 ECS 控制台,找到该实例。单击实例 ID,进入详情页,再单击本实例安全组 > 配置规则 >添加安全组规则。根据网站使用的端口配置新的安全组规则,放行网站使用的端口,最后单击确定。 可参考文档添加安全组规则。 根据报错情况分析 报错情况比较复杂,此处列出比较常见的几种报错内容: 403 报错:403 报错是一个大类,403 的报错基本上是权限问题,出现 403 报错时您需要检测权限配置问题。 403.1 错误是由于“执行”访问被禁止而造成的。若试图从目录中执行 CGI、ISAPI 或其他可执行程序,但该目录不允许执行程序时便会出现此种错误。403.2 错误是由于”读取”访问被禁止而造成的。导致此错误是由于没有可用的默认网页并且没有对目录启用目录浏览,或者要显示的 HTML 网页所驻留的目录仅标记为“可执行”或“脚本”权限。403.3 错误是由于“写入”访问被禁止而造成的。当试图将文件上载到目录或在目录中修改文件,但该目录不允许“写”访问时就会出现此种错误。403.4 错误是由于要求 SSL 而造成的。您必须在要查看的网页的地址中使用 HTTPS。403.5 错误是由于要求使用 128 位加密算法的 Web 浏览器而造成的。如果您的浏览器不支持 128 位加密算法就会出现这个错误,您可以连接微软网站进行浏览器升级。403.6 错误是由于 IP 地址被拒绝而造成的。如果服务器中有不能访问该站点的IP地址列表,并且您使用的 IP 地址在该列表中时您就会返回这条错误信息。403.7 错误是因为要求客户证书。当需要访问的资源要求浏览器拥有服务器能够识别的安全套接字层(SSL)客户证书时会返回此种错误。403.8 错误是由于禁止站点访问而造成的。若服务器中有不能访问该站点的 DNS 名称列表,而您使用的 DNS 名称在列表中时就会返回此种信息。请注意区别 403.6 与 403.8 错误。403.9 错误是由于连接的用户过多而造成的,由于 Web 服务器很忙,因通讯量过多而无法处理请求时便会返回这条错误。403.10 错误是由于无效配置而导致的错误。当您试图从目录中执行 CGI、ISAPI 或其他可执行程序,但该目录不允许执行程序时便会返回这条错误。403.11 错误是由于密码更改而导致无权查看页面。403.12 错误是由于映射器拒绝访问而造成的。若要查看的网页要求使用有效的客户证书,而您的客户证书映射没有权限访问该 Web 站点时就会返回映射器拒绝访问的错误。403.13 错误是由于需要查看的网页要求使用有效的客户证书而使用的客户证书已经被吊销,或者无法确定证书是否已吊销造成的。403.14 错误 Web 服务器被配置为不列出此目录的内容,拒绝目录列表。403.15 错误是由于客户访问许可过多而造成的。当服务器超出其客户访问许可限制时会返回此条错误。403.16 错误是由于客户证书不可信或者无效而造成的。403.17 错误是由于客户证书已经到期或者尚未生效而造成的。 404 报错:404 报错主要是页面显示问题或者页面的链接有问题,意味着链接指向的网页不存在,即原始网页的 URL 失效。当 Web 服务器接到类似请求时,会返回一个 404 状态码,告诉浏览器已请求的资源并不存在。导致这个错误的原因一般有以下几种情况: 无法在所请求的端口上访问 Web 站点。Web 服务扩展锁定策略阻止本请求。MIME 映射策略阻止本请求。网站更新改版,但某些局部板块沿用原来的模块,而原有的模块调用的文件已经被删除或转移了路径。跟踪访问的各类脚码或 CSS 文件无效但调用代码依然存在。某个目录直接删除(导致一段时间该目录的文件在被爬行时全部报 404 Not Found 错误)网页 URL 生成规则改变、网页文件更名或移动位置、导入链接拼写错误等,导致原来的 URL 地址无法访问 502 报错:当测试访问报错为 502 Bad Gateway,这是 Web 程序配置异常导致的。建议结合 Web 访问日志,检测一下 Web 程序配置的参数设置是否有异常。详情请参见 502 bad gateway问题的解决方法。503 报错:503 报错是一种 HTTP 状态码,与 404 同属一种网页状态出错码。两者的区别是:前者是服务器出错的一种返回状态,后者是网页程序没有相关结果后返回的一种状态。503 报错产生的原因有可能是以下几种情况: 网络管理员可能关闭应用程序池以执行维护。当请求到达时应用程序池队列已满。应用程序池标识没有使用预定义账户:网络服务。而自己配置了标识,但是配置的这个用户不属于 IIS_WPG 组。应用程序池启用了 CPU 监视,并且设置了 CPU 利用率超过一定百分比关闭应用程序池,而开发人员写的服务端页面 (.asp、.aspx) 执行效率不高,会引起 CPU 的长时间占用,最终达到设置的百分比,从而引起应用程序池关闭。应用程序池的性能选项卡的请求队列限制所填的数值太小,默认为 1000。某个目录直接删除(导致一段时间该目录的文件在被爬行时全部报 404 Not Found 错误)。网页 URL 生成规则改变、网页文件更名或移动位置、导入链接拼写错误等,导致原来的 URL 地址无法访问。该站点正在被攻击。对于最新型的攻击,其实是 DDoS 的一种派生,原理在于找数千个IP,同时向服务器的 Apache 发出请求,然后 立即断开,让 Apache 处于等待状态,致使 Apache 线程全部被填满,致使服务器死机。因此,为了保证大多数客户的利益,我们给每个空间,作出了每 19 秒 64 个 php 请求的限制。注意,是 php 请求,一般的图片请求和 html 请求不包括在内。该程序占用的 php 线程过多,有的程序没有进行好优化处理,一个点击即可产生数个,甚至数十个 php 线程。这样的话,几个点击就可以把该时段的64个 php 线程全部填满了。因此出现 503 错误。建议优化一下程序,尽量少用 require (请求)等语句。 如问题还未解决,请您记录排查结果、相关日志信息或截图,提交工单联系阿里云。
2019-12-01 23:11:57 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 注意:无法打开网站时,应该先搜索排查报错提示的含义,本文列举了一些常见的报错情况。 无法访问 ECS 实例上的网站时的分析思路: 根据报错情况分析网络通信问题 ECS Linux 实例网络通信问题排查ECS Windows 实例网络通信问题排查 端口通信问题 ECS Linux 实例端口通信问题ECS Windows 实例端口通信问题 防火墙配置异常 ECS Windows 实例远程无法连接,关闭防火墙后连接恢复正常ECS Linux 实例 SSH 无法连接,关闭 Iptables 后连接恢复正常 重新配置安全组公网规则 网络通信问题 ECS Linux 实例网络通信问题排查 执行 ifconfig 和 ip addr 网络检测命令查看 IP 地址。 执行命令 route -n 通过实例路由表查看网关。 ECS Windows 实例网络通信问题排查 打开 CMD,执行 ipconfig 网络检测命令查看 IP 地址。 执行命令 route print 通过实例路由表查看网关。 注意: 若网卡驱动未开启或网卡配置有问题,请检查网卡驱动,并重新安装。 关于网络相关问题的测试工具,详见 ping 丢包或不通时链路测试说明。 端口通信问题 ECS Linux 实例端口通信问题 执行命令 netstat –antpu | grep sshd 检测 sshd 服务的运行状态,确认端口是否有正常监听。 执行下列命令查看服务运行状态: CentOS6:service sshd statusCentOS7:systemctl status sshd 如果 sshd 服务没有正常运行,执行下列命令手动启动 sshd 服务: CentOS6:service sshd restartCentOS7:systemctl restart sshd 查看 sshd 程序日志 如果无法正常启动 sshd 服务,CentOS 6 系统一般会直接输出错误信息,而CentOS 7 启动时没有输出信息,需要通过 secure 日志进行查看。sshd 日志:/var/log/secure。 通过 secure 日志的报错信息,一般是可以定位绝大部分 sshd 启动异常的问题。 ECS Windows 实例端口通信问题 执行远程端口检测命令: Tasklist /svc | findstr “Ter”netstat –ano | findstr “$PID” 防火墙配置异常 ECS Windows 实例远程无法连接,关闭防火墙后连接恢复正常 前提条件:您只有在已授权可关闭防火墙的情况下,才能做该项排查。 调整防火墙配置策略,详见:ECS Windows 远程连接之防火墙设置。 调整后,重新进行远程连接。 ECS Linux 实例 SSH 无法连接,关闭 Iptables 后连接恢复正常 前提条件:您只有在已授权可关闭 Iptables 的情况下,才能做调整 Iptables 配置策略排查。 执行命令 iptables -nvL –line-number 查看防火墙规则: n 不对 IP 地址进行反查,加上这个参数显示速度会快很多。 v 输出详细信息,包含通过该规则的数据包数量、总字节数及相应的网络接口。 L 查看当前表的所有规则,默认查看的是 filter 表,如果要查看 NAT 表,可以加上 -t NAT 参数。 修改规则。(若您之前已设置过规则策略,执行命令 cp -a /etc/sysconfig/iptables /etc/sysconfig/iptables.bak 保存一份原有的 Iptables 文件,避免丢失已设置过策略。) 执行命令 iptables -F 清空实例上所有的规则。 执行命令 iptables -P INPUT DROP 拒绝 INPUT 方向所有的请求都。 注意:线上业务请勿直接操作,会导致业务直接中断。 执行下列命令放行端口 22: iptables -A INPUT -p tcp --dport 22 -j ACCEPTiptables -A OUTPUT -p tcp --sport 22 -j ACCEPT执行下列命令指定 IP 访问端口 22: iptables -I INPUT -s 192.168.1.1 -p tcp --dport 22 -j ACCEPT 说明: 192.168.1.1 为请求端 IP 地址。 执行命令 iptables -L 查看添加的规则是否生效。 执行命令 iptables-save > /etc/sysconfig/iptables 保存添加的规则。 执行命令 service iptables restart 或 /etc/init.d/iptables restart 重启 Iptables。 执行命令 systemctl reboot 重启实例验证配置。 重新进行 SSH 连接。 重新配置安全组公网规则 原因分析:安全组默认没有放行网站使用的端口(如 80 端口)。您需要自行放行该接口。 解决方法: 登录 ECS 控制台,找到该实例。单击实例 ID,进入详情页,再单击本实例安全组 > 配置规则 >添加安全组规则。根据网站使用的端口配置新的安全组规则,放行网站使用的端口,最后单击确定。 可参考文档添加安全组规则。 根据报错情况分析 报错情况比较复杂,此处列出比较常见的几种报错内容: 403 报错:403 报错是一个大类,403 的报错基本上是权限问题,出现 403 报错时您需要检测权限配置问题。 403.1 错误是由于“执行”访问被禁止而造成的。若试图从目录中执行 CGI、ISAPI 或其他可执行程序,但该目录不允许执行程序时便会出现此种错误。403.2 错误是由于”读取”访问被禁止而造成的。导致此错误是由于没有可用的默认网页并且没有对目录启用目录浏览,或者要显示的 HTML 网页所驻留的目录仅标记为“可执行”或“脚本”权限。403.3 错误是由于“写入”访问被禁止而造成的。当试图将文件上载到目录或在目录中修改文件,但该目录不允许“写”访问时就会出现此种错误。403.4 错误是由于要求 SSL 而造成的。您必须在要查看的网页的地址中使用 HTTPS。403.5 错误是由于要求使用 128 位加密算法的 Web 浏览器而造成的。如果您的浏览器不支持 128 位加密算法就会出现这个错误,您可以连接微软网站进行浏览器升级。403.6 错误是由于 IP 地址被拒绝而造成的。如果服务器中有不能访问该站点的IP地址列表,并且您使用的 IP 地址在该列表中时您就会返回这条错误信息。403.7 错误是因为要求客户证书。当需要访问的资源要求浏览器拥有服务器能够识别的安全套接字层(SSL)客户证书时会返回此种错误。403.8 错误是由于禁止站点访问而造成的。若服务器中有不能访问该站点的 DNS 名称列表,而您使用的 DNS 名称在列表中时就会返回此种信息。请注意区别 403.6 与 403.8 错误。403.9 错误是由于连接的用户过多而造成的,由于 Web 服务器很忙,因通讯量过多而无法处理请求时便会返回这条错误。403.10 错误是由于无效配置而导致的错误。当您试图从目录中执行 CGI、ISAPI 或其他可执行程序,但该目录不允许执行程序时便会返回这条错误。403.11 错误是由于密码更改而导致无权查看页面。403.12 错误是由于映射器拒绝访问而造成的。若要查看的网页要求使用有效的客户证书,而您的客户证书映射没有权限访问该 Web 站点时就会返回映射器拒绝访问的错误。403.13 错误是由于需要查看的网页要求使用有效的客户证书而使用的客户证书已经被吊销,或者无法确定证书是否已吊销造成的。403.14 错误 Web 服务器被配置为不列出此目录的内容,拒绝目录列表。403.15 错误是由于客户访问许可过多而造成的。当服务器超出其客户访问许可限制时会返回此条错误。403.16 错误是由于客户证书不可信或者无效而造成的。403.17 错误是由于客户证书已经到期或者尚未生效而造成的。 404 报错:404 报错主要是页面显示问题或者页面的链接有问题,意味着链接指向的网页不存在,即原始网页的 URL 失效。当 Web 服务器接到类似请求时,会返回一个 404 状态码,告诉浏览器已请求的资源并不存在。导致这个错误的原因一般有以下几种情况: 无法在所请求的端口上访问 Web 站点。Web 服务扩展锁定策略阻止本请求。MIME 映射策略阻止本请求。网站更新改版,但某些局部板块沿用原来的模块,而原有的模块调用的文件已经被删除或转移了路径。跟踪访问的各类脚码或 CSS 文件无效但调用代码依然存在。某个目录直接删除(导致一段时间该目录的文件在被爬行时全部报 404 Not Found 错误)网页 URL 生成规则改变、网页文件更名或移动位置、导入链接拼写错误等,导致原来的 URL 地址无法访问 502 报错:当测试访问报错为 502 Bad Gateway,这是 Web 程序配置异常导致的。建议结合 Web 访问日志,检测一下 Web 程序配置的参数设置是否有异常。详情请参见 502 bad gateway问题的解决方法。503 报错:503 报错是一种 HTTP 状态码,与 404 同属一种网页状态出错码。两者的区别是:前者是服务器出错的一种返回状态,后者是网页程序没有相关结果后返回的一种状态。503 报错产生的原因有可能是以下几种情况: 网络管理员可能关闭应用程序池以执行维护。当请求到达时应用程序池队列已满。应用程序池标识没有使用预定义账户:网络服务。而自己配置了标识,但是配置的这个用户不属于 IIS_WPG 组。应用程序池启用了 CPU 监视,并且设置了 CPU 利用率超过一定百分比关闭应用程序池,而开发人员写的服务端页面 (.asp、.aspx) 执行效率不高,会引起 CPU 的长时间占用,最终达到设置的百分比,从而引起应用程序池关闭。应用程序池的性能选项卡的请求队列限制所填的数值太小,默认为 1000。某个目录直接删除(导致一段时间该目录的文件在被爬行时全部报 404 Not Found 错误)。网页 URL 生成规则改变、网页文件更名或移动位置、导入链接拼写错误等,导致原来的 URL 地址无法访问。该站点正在被攻击。对于最新型的攻击,其实是 DDoS 的一种派生,原理在于找数千个IP,同时向服务器的 Apache 发出请求,然后 立即断开,让 Apache 处于等待状态,致使 Apache 线程全部被填满,致使服务器死机。因此,为了保证大多数客户的利益,我们给每个空间,作出了每 19 秒 64 个 php 请求的限制。注意,是 php 请求,一般的图片请求和 html 请求不包括在内。该程序占用的 php 线程过多,有的程序没有进行好优化处理,一个点击即可产生数个,甚至数十个 php 线程。这样的话,几个点击就可以把该时段的64个 php 线程全部填满了。因此出现 503 错误。建议优化一下程序,尽量少用 require (请求)等语句。 如问题还未解决,请您记录排查结果、相关日志信息或截图,提交工单联系阿里云。
2019-12-01 23:11:56 0 浏览量 回答数 0

回答

详细解答可以参考官方帮助文档 注意:无法打开网站时,应该先搜索排查报错提示的含义,本文列举了一些常见的报错情况。 无法访问 ECS 实例上的网站时的分析思路: 根据报错情况分析网络通信问题 ECS Linux 实例网络通信问题排查ECS Windows 实例网络通信问题排查 端口通信问题 ECS Linux 实例端口通信问题ECS Windows 实例端口通信问题 防火墙配置异常 ECS Windows 实例远程无法连接,关闭防火墙后连接恢复正常ECS Linux 实例 SSH 无法连接,关闭 Iptables 后连接恢复正常 重新配置安全组公网规则 网络通信问题 ECS Linux 实例网络通信问题排查 执行 ifconfig 和 ip addr 网络检测命令查看 IP 地址。 执行命令 route -n 通过实例路由表查看网关。 ECS Windows 实例网络通信问题排查 打开 CMD,执行 ipconfig 网络检测命令查看 IP 地址。 执行命令 route print 通过实例路由表查看网关。 注意: 若网卡驱动未开启或网卡配置有问题,请检查网卡驱动,并重新安装。 关于网络相关问题的测试工具,详见 ping 丢包或不通时链路测试说明。 端口通信问题 ECS Linux 实例端口通信问题 执行命令 netstat –antpu | grep sshd 检测 sshd 服务的运行状态,确认端口是否有正常监听。 执行下列命令查看服务运行状态: CentOS6:service sshd statusCentOS7:systemctl status sshd 如果 sshd 服务没有正常运行,执行下列命令手动启动 sshd 服务: CentOS6:service sshd restartCentOS7:systemctl restart sshd 查看 sshd 程序日志 如果无法正常启动 sshd 服务,CentOS 6 系统一般会直接输出错误信息,而CentOS 7 启动时没有输出信息,需要通过 secure 日志进行查看。sshd 日志:/var/log/secure。 通过 secure 日志的报错信息,一般是可以定位绝大部分 sshd 启动异常的问题。 ECS Windows 实例端口通信问题 执行远程端口检测命令: Tasklist /svc | findstr “Ter”netstat –ano | findstr “$PID” 防火墙配置异常 ECS Windows 实例远程无法连接,关闭防火墙后连接恢复正常 前提条件:您只有在已授权可关闭防火墙的情况下,才能做该项排查。 调整防火墙配置策略,详见:ECS Windows 远程连接之防火墙设置。 调整后,重新进行远程连接。 ECS Linux 实例 SSH 无法连接,关闭 Iptables 后连接恢复正常 前提条件:您只有在已授权可关闭 Iptables 的情况下,才能做调整 Iptables 配置策略排查。 执行命令 iptables -nvL –line-number 查看防火墙规则: n 不对 IP 地址进行反查,加上这个参数显示速度会快很多。 v 输出详细信息,包含通过该规则的数据包数量、总字节数及相应的网络接口。 L 查看当前表的所有规则,默认查看的是 filter 表,如果要查看 NAT 表,可以加上 -t NAT 参数。 修改规则。(若您之前已设置过规则策略,执行命令 cp -a /etc/sysconfig/iptables /etc/sysconfig/iptables.bak 保存一份原有的 Iptables 文件,避免丢失已设置过策略。) 执行命令 iptables -F 清空实例上所有的规则。 执行命令 iptables -P INPUT DROP 拒绝 INPUT 方向所有的请求都。 注意:线上业务请勿直接操作,会导致业务直接中断。 执行下列命令放行端口 22: iptables -A INPUT -p tcp --dport 22 -j ACCEPTiptables -A OUTPUT -p tcp --sport 22 -j ACCEPT执行下列命令指定 IP 访问端口 22: iptables -I INPUT -s 192.168.1.1 -p tcp --dport 22 -j ACCEPT 说明: 192.168.1.1 为请求端 IP 地址。 执行命令 iptables -L 查看添加的规则是否生效。 执行命令 iptables-save > /etc/sysconfig/iptables 保存添加的规则。 执行命令 service iptables restart 或 /etc/init.d/iptables restart 重启 Iptables。 执行命令 systemctl reboot 重启实例验证配置。 重新进行 SSH 连接。 重新配置安全组公网规则 原因分析:安全组默认没有放行网站使用的端口(如 80 端口)。您需要自行放行该接口。 解决方法: 登录 ECS 控制台,找到该实例。单击实例 ID,进入详情页,再单击本实例安全组 > 配置规则 >添加安全组规则。根据网站使用的端口配置新的安全组规则,放行网站使用的端口,最后单击确定。 可参考文档添加安全组规则。 根据报错情况分析 报错情况比较复杂,此处列出比较常见的几种报错内容: 403 报错:403 报错是一个大类,403 的报错基本上是权限问题,出现 403 报错时您需要检测权限配置问题。 403.1 错误是由于“执行”访问被禁止而造成的。若试图从目录中执行 CGI、ISAPI 或其他可执行程序,但该目录不允许执行程序时便会出现此种错误。403.2 错误是由于”读取”访问被禁止而造成的。导致此错误是由于没有可用的默认网页并且没有对目录启用目录浏览,或者要显示的 HTML 网页所驻留的目录仅标记为“可执行”或“脚本”权限。403.3 错误是由于“写入”访问被禁止而造成的。当试图将文件上载到目录或在目录中修改文件,但该目录不允许“写”访问时就会出现此种错误。403.4 错误是由于要求 SSL 而造成的。您必须在要查看的网页的地址中使用 HTTPS。403.5 错误是由于要求使用 128 位加密算法的 Web 浏览器而造成的。如果您的浏览器不支持 128 位加密算法就会出现这个错误,您可以连接微软网站进行浏览器升级。403.6 错误是由于 IP 地址被拒绝而造成的。如果服务器中有不能访问该站点的IP地址列表,并且您使用的 IP 地址在该列表中时您就会返回这条错误信息。403.7 错误是因为要求客户证书。当需要访问的资源要求浏览器拥有服务器能够识别的安全套接字层(SSL)客户证书时会返回此种错误。403.8 错误是由于禁止站点访问而造成的。若服务器中有不能访问该站点的 DNS 名称列表,而您使用的 DNS 名称在列表中时就会返回此种信息。请注意区别 403.6 与 403.8 错误。403.9 错误是由于连接的用户过多而造成的,由于 Web 服务器很忙,因通讯量过多而无法处理请求时便会返回这条错误。403.10 错误是由于无效配置而导致的错误。当您试图从目录中执行 CGI、ISAPI 或其他可执行程序,但该目录不允许执行程序时便会返回这条错误。403.11 错误是由于密码更改而导致无权查看页面。403.12 错误是由于映射器拒绝访问而造成的。若要查看的网页要求使用有效的客户证书,而您的客户证书映射没有权限访问该 Web 站点时就会返回映射器拒绝访问的错误。403.13 错误是由于需要查看的网页要求使用有效的客户证书而使用的客户证书已经被吊销,或者无法确定证书是否已吊销造成的。403.14 错误 Web 服务器被配置为不列出此目录的内容,拒绝目录列表。403.15 错误是由于客户访问许可过多而造成的。当服务器超出其客户访问许可限制时会返回此条错误。403.16 错误是由于客户证书不可信或者无效而造成的。403.17 错误是由于客户证书已经到期或者尚未生效而造成的。 404 报错:404 报错主要是页面显示问题或者页面的链接有问题,意味着链接指向的网页不存在,即原始网页的 URL 失效。当 Web 服务器接到类似请求时,会返回一个 404 状态码,告诉浏览器已请求的资源并不存在。导致这个错误的原因一般有以下几种情况: 无法在所请求的端口上访问 Web 站点。Web 服务扩展锁定策略阻止本请求。MIME 映射策略阻止本请求。网站更新改版,但某些局部板块沿用原来的模块,而原有的模块调用的文件已经被删除或转移了路径。跟踪访问的各类脚码或 CSS 文件无效但调用代码依然存在。某个目录直接删除(导致一段时间该目录的文件在被爬行时全部报 404 Not Found 错误)网页 URL 生成规则改变、网页文件更名或移动位置、导入链接拼写错误等,导致原来的 URL 地址无法访问 502 报错:当测试访问报错为 502 Bad Gateway,这是 Web 程序配置异常导致的。建议结合 Web 访问日志,检测一下 Web 程序配置的参数设置是否有异常。详情请参见 502 bad gateway问题的解决方法。503 报错:503 报错是一种 HTTP 状态码,与 404 同属一种网页状态出错码。两者的区别是:前者是服务器出错的一种返回状态,后者是网页程序没有相关结果后返回的一种状态。503 报错产生的原因有可能是以下几种情况: 网络管理员可能关闭应用程序池以执行维护。当请求到达时应用程序池队列已满。应用程序池标识没有使用预定义账户:网络服务。而自己配置了标识,但是配置的这个用户不属于 IIS_WPG 组。应用程序池启用了 CPU 监视,并且设置了 CPU 利用率超过一定百分比关闭应用程序池,而开发人员写的服务端页面 (.asp、.aspx) 执行效率不高,会引起 CPU 的长时间占用,最终达到设置的百分比,从而引起应用程序池关闭。应用程序池的性能选项卡的请求队列限制所填的数值太小,默认为 1000。某个目录直接删除(导致一段时间该目录的文件在被爬行时全部报 404 Not Found 错误)。网页 URL 生成规则改变、网页文件更名或移动位置、导入链接拼写错误等,导致原来的 URL 地址无法访问。该站点正在被攻击。对于最新型的攻击,其实是 DDoS 的一种派生,原理在于找数千个IP,同时向服务器的 Apache 发出请求,然后 立即断开,让 Apache 处于等待状态,致使 Apache 线程全部被填满,致使服务器死机。因此,为了保证大多数客户的利益,我们给每个空间,作出了每 19 秒 64 个 php 请求的限制。注意,是 php 请求,一般的图片请求和 html 请求不包括在内。该程序占用的 php 线程过多,有的程序没有进行好优化处理,一个点击即可产生数个,甚至数十个 php 线程。这样的话,几个点击就可以把该时段的64个 php 线程全部填满了。因此出现 503 错误。建议优化一下程序,尽量少用 require (请求)等语句。 如问题还未解决,请您记录排查结果、相关日志信息或截图,提交工单联系阿里云。
2019-12-01 23:11:56 0 浏览量 回答数 0

云产品推荐

上海奇点人才服务相关的云产品 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 阿里云AIoT