精华内容
下载资源
问答
  • 云平台在设备制造企业应用,主要包括设备企业现状,的解决方案。云平台优点 以及应用个例。
  • 基础-企业云平台技术及应用 1、云计算与大数据 2、云计算基础 3、企业云平台架构 看完以后你会情不自禁的喊“oh,yes....oh,no....”
  • 随着时代的到来和SaaS概念的引入,越来越多的企业开始选择由SaaS应用提供商、运营商等通过互联网平台提供SaaS应用服务,SaaS应用的数据量面临着TB级的增长速度;不同的SaaS应用体系,提供的数据结构也不完全相同,...
  • 开源容器OpenShift 构建基于Kubernetes的企业应用云平台
  • 开源容器OpenShift构建基于Kubernetes的企业应用云平台.pdf,中文版,清晰带目录完整版。
  • 开源容器OpenShift构建基于Kubernetes的企业应用云平台,Red Hat官方技术专家出品,陈耿
  • 《开源容器OpenShift:构建基于Kuberes的企业应用云平台》手打完美书签
  • 当今,企业”上云”节奏正在加速,特别是在以人工智能技术为代表的新一波技术浪潮推动下,企业一方面通过技术增强了自身的数据存储连接、计算以及智能应用能力;另一方面,利用基于云计算之上的大数据、人工智能等...
  • 开源容器OpenShift:构建基于Kubernetes的企业应用云平台
  • 开源容器OpenShift 构建基于Kubernetes的企业应用云平台 ,陈耿 ,P253 ,2017.06 高清扫描版 带标签
  • 云表是一个快速开发管理系统软件的平台,一种通过画表格来开发管理软件无代码纯中文开发工具,适应全行业各种场景应用,可以与主流信息系统无缝集成。利用云表平台,没学过编程语言的人,也可以像搭建积木一样开发出...
  • 【开源容器OpenShift:构建基于Kubernetes的企业应用云平台】 正文.pdf
  • 《开源容器OpenShift:构建基于Kuberes的企业应用云平台
  • 【开源容器OpenShift:构建基于Kubernetes的企业应用云平台】 文前.pdf
  • 1个云平台,超过30项企业应用
  • 企业云应用平台的实践和思考

    千次阅读 2016-07-18 16:36:31
    今天要讲的题目是《企业平台的实践和思考》, 主要涉及一些基于环境的应用构建的技术, 讲一下... 基于应用平台,我将它分成两类:  一块是资源管理技术, 比如私有如OpenStack、CloudStack或者公有
            今天要讲的题目是《企业级云平台的实践和思考》, 主要涉及一些基于云环境的应用构建的技术, 讲一下我在这方面的一些实践经历和一些思考, 主要讲两个参与开发的系统的功能和设计为主,不会涉及太多细节技术。 当然,我们也可以就一些点具体讨论一下。 
    

      资源管理和应用管理

      基于云的应用平台,我将它分成两类:

      一块是资源管理技术, 比如私有云如OpenStack、CloudStack或者公有云技术; 还有就是资源集群管理技术, 在Docker这个技术领域,个人感觉集群技术更适用。

      另一块就是应用的构建和管理技术, 包括应用资源管理,应用构建、部署、维护、 监控和弹性扩展等技术,以下我会就这两块来分享。

      先看集群技术,大家都知道,云计算、大数据相关的技术最早都是从集群管理技术开始的,”Google的几篇经典论文介绍了当前大数据技术格局的相关基础技术,包括GFS、MapReduce、BigTable及Chubby等。另外就是Borg这个技术,它是Google内部一切服务的基础。最近朋友圈大家也不断转发最新的Borg的论文, 其实国内外互联网公司也有类似的系统,如Twitter中使用的由加州大学伯克利分校AMPLab开发的Mesos,国内公司如百度的Volunteer Computing平台以及腾讯SOSO部门开发的台风系统。 Hadoop社区2.X版本引入的Yarn也是类似思路的产物。这些技术因为Docker或者Linux上的容器技术的出现都有了新的变化, 就是我们大家都知道的k8s、Mesos+Marathon、百度Matrix、腾讯Gaia等。

      以上技术都是立足互联网应用的,企业级其实也有类似的技术。 分布式领域有一篇著名的论文《Utopia: a Load Sharing Facility for Large, Heterogeneous Distributed Computer Systems 》,这个算是分布式计算领域的开山几篇论文之一,1993年发表的,包括Google的几篇著名论文就引用了它,它描述的就是当前流行的分布式计算体系,论文作者就是分布式计算公司Platform Computing的创始人。

      资源管理器:Platform EGO

      下来我们要介绍的Platform EGO就是这个技术在HPC等分布式企业领域演进10年后的2.0架构中的资源管理技术, 在最近北京、西安的Mesos Meetup都有所介绍, 就是所谓的IBM Platform DCOS技术,下面是其中一张PPT。

      

    企业级云平台的实践和思考

     

      上面的图中所有绿色都是IBM Platform的产品,其中一个核心就是它的资源管理器 Resource Manager(EGO/DCOS)。 它是2004~2005年开始设计开发,和上层的任务负载调度系统LSF,Symphony合起来构成业界最早出现的二层调度系统,至少是针对企业市场交付的第一款类似产品。

      我2005年在腾讯开始接触分布式系统设计开发, 2006年加入Platform Computing,我2006~2010年之间四年多一直参与开发这个产品和基于它的云管理产品Platform ISF。Platform ISF在2011年被Forrester评价为私有云业界第一, 但是IBM收购Platform后相关的策略变化导致它从产品序列中退出作为IBM Platform Cluster Manager的一部分保留。

      EGO架构

      下面来看EGO的一个模块图 :

      

    企业级云平台的实践和思考

     

      这是一个非官方的架构图,是我根据对系统的理解和当时的一些规划画的,不代表现在情况。它是一个典型的SOA架构,核心包括的LIM、PEM和Master组成的核心服务, 上层包括initd Service EGOSC、name Service egosd、crond Service - Cron、web api service- wsg、自服务门户、分析服务等,也支持C、Java、Python API,后来也有Restful API。 我有意将它画得像一个人,有手有脚,有大脑主要想表达其中核心资源管理问题3块, 一是收集信息,一直执行任务,一是资源分配调度, 调度就是大脑,收集信息和执行任务就是手脚。

      从上面的图中能够看出来,EGO核心Master它是基于插件的架构, 包括资源插件、安全插件、调度插件、部署(provision)插件、 事件插件和执行插件。

      LIM( Load Information Manager)是一个用来收集信息的Master-Slave分布式系统,作为默认的资源插件使用。 实际上EGO Master会保留标准的API,外部系统可以容易地增加新的资源类型, 比如软件License,网络拓扑管理等资源信息。 EGO将各种资源被抽象为有类型的Resource Entity和具有一组属性,用name-type-value 3元组来描述, 这个概念等价于DMTF组织定义的CIM(Common Information Modle)并具有同样的表达能力,实践中也确实覆盖了软件,硬件等各种需求。

      PEM(Process Execution Manager)是执行系统, 也是一个主从结构的分布式系统, 默认master内嵌在EGO Maser中,但后续设计会将它拆除来通过插件完成, 同时支持其他各种执行系统。 这里EGO会为每个外部系统分配一部分资源(抽象单位为slot,可以通过配置定义slot具体对应为多少MEM、CPU或者其他资源), 然后远程执行一个任务。一个任务的早期抽象概念叫Container,后来更改为Activity, 我看到的设计文档中关于这部分提到了容器/分区等各种Unix类系统上的虚拟化技术, 不过没有具体的实现。在Linux上,后来也出现对LXC的需求,应该也没有实现。

      调度插件是资源管理的重要组成部分,EGO支持多个调度器, 可以同时支持进程分配,虚拟机资源分配, 批处理任务资源调度等多种资源分配需求。 我在Platform的最后一阶段工作还设计了开发调度策略的DSL语言和默认实现,支持管理员用python语言开发自定义的调度策略。

      EGO调度策略

      来看一个经典的EGO调度策略:

      

    企业级云平台的实践和思考

     

      从上面的PPT来看, EGO的调度策略会考虑应用的Topo结构、资源的负载、资源拓扑逻辑、网络速率、包括应用的运行时间(比如分时运行、周期性运行等各种模型)。另外也考虑了运行期中的资源分片问题,提供了资源整理和迁移的功能。

      安全插件支持基本的User/Password、Token/Credential、SSL等, 还包括各种商业的系统如Kerberos、SiteMinder等,当然也支持企业常用的AD、LADP系统,也支持基于RABC的权限管理。这里要多说一点, 经常大家会听到3A或者4A这种说法, 就是认证Authentication、账号Account、授权Authorization、审计Audit,中文名称为统一安全管理平台解决方案。 EGO的这部分设计就是为了cover企业在这方面的需求, 当时相关的功能陆续做了近1年才基本满足相关的需求。EGO原生设计就支持多租户, 很容易切换到当前云的环境和需求。

      部署插件是为了满足各种上层应用系统二进制软件分发的需求,有基于FTP,NFS等各种实现。事件插件主要是将系统中关于资源生命周期的各种事件通知出去的, 支持SNMP等协议。

      与Mesos、Yarn、Kubernetes的对比

      比较EGO和Mesos、Yarn和现在的Kubernetes, 我们发现企业级应用系统除了核心的功能,管理功能非常重要,基本是3分功能, 7分管理。

      细说一下,为了描述资源使用者, 设计了用户、消费者、client/session等概念来描述使用资源的人、组织和应用程序。 资源的抽象考虑各种扩展,采用业界标准CIM模型。资源分配过程支持优先级,预分配,实时分配,资源抢占等各种机制。资源支持运行进程、VM、容器等各种资源消耗模式, 当年我们经常讲的一句话, “分配资源后拿来什么也不干,也是一种资源使用方式”。 如果大家有兴趣,可以去看看《面向模式的软件架构卷3:资源管理模式》, 这本书将资源管理中的问题和解决方案都进行了抽象,值得一读。 综合来看, 对于企业级的资源管理或者集群技术, 可管理是个重要的需求。它要求的管理是细粒度的,全方位的。 另外它要和企业已有的IT架构和管理整合, 在软件架构灵活性和适应性要求较高。

      应用管理

      刚才讲的是资源管理或者集群管理的技术,再来看看应用层面的技术。先看一下天云SkyForm应用管理产品的架构图:

      

    企业级云平台的实践和思考

     

      这个产品设计能够自动的按照模板定义自动申请资源、部署软件、配置系统,可以支持OpenStack、CloudStack等开源云平台,支持各种常见的 Apache Tomcat、MySQL,还支持Hadoop、HPC系统的自动部署和配置, 同时支持分布式运维任务执行管理、软件仓库管理等。开发这个系统是在2012年,当时社区还没有好成型的类似系统,尤其是没有统一的业界认可的软件分发格式。所以我们自己基于RPM等格式定义了一套软件包格式和描述语言, 另外还设计了图形化应用设计器,支持拖拽式应用设计,效果如下 :

      

    企业级云平台的实践和思考

     

      在用户处实际使用的效果并不理想, 比如用户的应用不能或很难改造, 更需要应用拓扑展示, 另外我们定义的软件包格式也很难推行。用户需要应用性能监控数据, 同时希望基于性能的AutoScaling能力。 具体实现AutoScaling的过程中,也有两种需求: 一种是用户应用自主控制的方式,即通过API来扩展系统; 一种是采用系统提供的AutoScaling服务, 通过配置扩展策略和原始监控策略有系统自动实现。从管理的角度, 应用平台的建设和管理者的关注点在于应用的全貌, 比如应用的资源使用情况, 应用的运行数据(包括资源利用率, 业务处理能力), 应用弹性管理能力, 继而得到整体系统资源的使用情况以此为系统建设和再投资决策做出数据支撑。

      架构演进

      基于以上的用户需求,我们参考AWS的实践将原来的一体化设计拆分并扩展为部署服务, cloudwatch服务和AutoScaling服务。未来的应用基本都有大量数据处理的需求,所以需要支持大数据技术,再加上Docker的出现, 整体软件架构演进到下面的阶段:

      

    企业级云平台的实践和思考

     

      架构演进有以下几点动机:

      互联网技术在企业逐步推广,我们看到传统企业在不断学习互联网的技术。

      企业环境一般为混搭结构, 需要支持容器, VM和传统的遗产应用。

      微服务架构正在互联网和企业软件开发中大量使用,应用管理平台需要针对它做一定设计。

      在这个产品开发过程中的经验就是基于服务的架构和服务内部的微服务架构是满足当前云化应用的一个好的实践。

      综合以上两个产品的经验和教训,建议设计和开发人员多研究一下AWS,它的服务设计和定义在企业领域有很多可借鉴的, 比如它就有专门的IAM服务来管理人、组织、安全、权限方面的需求。而且它的设计已经从局部模块的插件化的抽象方式上升到了整体架构的服务化抽象, 如何具体应用需要大家认真揣摩。我的实践总结下来为:功能层级化、架构SOA化、服务内插件化、 配合开发技术平台化。

      Q&A

      Q:你认为面向资源和面向应用架构的区别是?

      A:一个关注的资源的供给,一个关注应用的架构、实现第2个其中会有一部分资源的申请、管理问题。面向应用更关注业务,所以上层的应用往往叫做负载管理系统或任务管理系统。

      Q:大数据HDFS是在虚拟机VM里面还是真实物理机里面?

      A:建议不要使用虚拟机,除非能将IOPS搞到类似物理机的程度,或者就是用来做算法验证,要不对存储系统冲击太大。

      Q:目前 作者分享的一般都是基于互联网,针对企业级其实也有类似的技术,具体有哪些,怎么实现?

      A:我介绍的第一个产品EGO就是完全面向企业的, 主要给金融等领域使用,比如花旗银行,倒闭的雷曼兄弟等 ,现在也在电信等行业使用,互联网行业基本没有用户。

      Q:在服务化的过程中,架构如何同时兼顾老的非服务化的部件和服务化的服务?

      A:其实我们有个实践就是,有的服务或部件就让它随着时间over吧。 重要的考虑云化,实在不行考虑盖个帽子封装成服务,就是经典的设计模式中的门面,adapter等的在服务层面的使用,也可以叫做服务网关之类的。

      Q:你们是如何对集群资源做到细粒度的管理的,能说说你们遇到过哪些坑吗?

      A:主要通过设计了资源组和各种资源tag来过滤资源,同时设计了一种规则语言和引擎支持select、order,支持各种数学运算和与、或非的逻辑关系来让用户定义资源的需求。最大的坑其实就是资源粒度定义有点问题,一度都出现零点几个slot的情况,其实简单点就好了,甚至随机分配都会有个很好的效果,毕竟这个宇宙也是混沌的,呵呵。当然只是个人的看法,其他人不一定同意。

      Q:你们肯定有考虑过硬件资源使用情况负载的问题,Docker容器上前段时间倒是出了监控宝,可以监控容器的各种资源使用情况,但是想问下今天您提到的“应用的资源使用情况”,你们是做的实时监控吗?这个是怎么实现的?

      A:原来EGO的调度策略一直有个基于负载的规则,LIM会准实时的收集系统的负载,包括CPU、MEM、DISK等信息然后汇总到master LIM供 EGO master使用。 天云的系统构建了一套自己的监控体系、也支持zabbix采集信息,还支持名的APM公司newrelic的agent 协议,另外也开放了API,可以自己定制监控采集系统。 监控宝我们也看过,类似的都有几个,不过这是应用开发团队需要自己选择的。

      Q:Auto Scaling过程中是需要停止服务吗?

      A:不需要停止服务,参考AWS和具体业务,我们设计了多个AutoScaling group,一部分用于系统基本运行需要的最少的资源,其他则为动态改变的,也就是说会保留最少的服务节点。

      Q:天云的云平台如何解决单点问题,除了热备冷备,实现了分布式吗,怎么实现的,分布式的事务怎么处理的?

      A:天云云平台一开始就是Load Balance模式设计,类似OpenStack,单点主要就是数据库。DB的问题也是采用常规的做法,当然也可以采用类似etcd、zk的方式,不过规模大不了。

      Q:我觉得云平台最吸引人是弹性调度,能否就弹性调度如何实现这个问题,分享些经验给我们?

      A:个人建议,多研究一下AWS的autoScaling服务,比如QingCloud的调度服务其实也是它的简化版。它支持定时、手动、规则驱动等触发方式,对执行的动作也有很多可配置的方式,比如发消息、自动执行动作等。

      Q:EGO中对容错机制是怎么理解的么,能否讲下?

      A:EGO的容错分了2部分,一部分是系统本身的,主要靠共享存储来保存核心数据,然后每个模块做到可以随意重启。 应用主要靠其中的egosc,它会监视应用的模块,做到按照定义的规则执行重启等动作,应用本身的数据一致问题,则要应用自己处理。

      Q:能介绍下Symphony在DCOS中的作用么?

      A:Symphony整体是个SOA的任务或负责管理系统,底层需要一个资源管理系统,类似Hadoop、Habase与Yarn的关系。

      Q:EGO核心Master它是基于插件的架构,支持热插拔吗?

      A:没有采用热插拔。 因为系统的每个组件都能够做到重启不丢数据,启动时会和相关模块同步数据并纠正不一致的地方,所以对系统稳定运行没有影响,类似Google的思路,做到每个点都能很容易的重启。

      Q:能否介绍一个典型的调度器实现策略?如何考虑资源和需求的?

      A:简单来说,就是将所有的资源请求先放到队列中,然后针对请求采用背包算法,或者线性规划算法来找一个次优解就行。因为要近实时的给出资源分配结果,所以没有最优解。

      Q:云平台的容灾措施是怎么样,有什么好的方案?

      A:容灾关键还是数据,关键在企业的存储设计,我也没有太多建议。

      Q:Docker网络选择是host还是nat,性能损失分别是多少?

      A:Docker网络真实只在自己环境管理自己SkyForm使用过,其他的都是实验室环境,没有真实线上环境测试,没法给出实际数据,建议去看一下新浪、雪球等公司的建议。 当前只是在一些项目中实验Docker,没有大规模去推。

      Q:目前我们都提倡服务抽象、组合化,我们目的是为了向稳定、便捷的方向进取,那么,我想问是着重管理,还是着重技术功能方向呢?

      A:具体分析,建议按照建设、实用、运维、优化管理的次序来考虑。

      =======================================================================================

      本文根据Dockone技术分享整理而成。分享人贾琨,云基地旗下初创公司北京天云融创软件技术有限公司产品研发总监兼架构师,2005年开始从事大规模Web服务、HPC/网格及云管理平台等分布式系统研发,历任腾讯Qzone、IBM Platform Computing资源管理调度系统,华为FusionSphere等产品的开发、架构及产品设计工作。精通各种IaaS平台、资源管理、资源调度等相关技术,2010年开始从事OpenStack研发、社区活动,当前主要关注Docker及相关资源管理技术,如Mesos、Yarn等。

    展开全文
  • Rainbond 是原生且易用的原生应用管理平台原生应用交付的最佳实践,简单易用。专注于以应用中心的理念。赋能企业搭建原生开发原生交付。 对于企业: Rainbond 是开箱即用的原生平台,借助 ...
  • 企业应用云化架构设计 周小四 Ray Zhou 青云QingCloud AppCenter及大数据平台负责人 Agenda 概述 架构演变 标准化平台设计 概述 应用常态化 云计算常态化 极低门槛 标准化平台 架构演变 完全孤立每个应用独立开发 ...
  • 开源容器 OpenShift 构建基于Kubernetes的企业应用云平台
  • 阿里Web应用防火墙价格

    千次阅读 2018-04-09 16:18:31
    Web应用防火墙(Web Application Firewall, 简称 WAF), 是阿里基于10余年攻防经验自主研发的安全产品。基于安全大数据能力实现,通过防御SQL注入、XSS跨...关于Web应用防火墙的详细介绍请见:阿里全新Web应用防火...

    Web应用防火墙(Web Application Firewall, 简称 WAF), 是阿里基于10余年攻防经验自主研发的安全产品。基于云安全大数据能力实现,通过防御SQL注入、XSS跨站脚本、常见Web服务器插件漏洞、木马上传、非授权核心资源访问等OWASP常见攻击,过滤海量恶意访问,避免您的网站资产数据泄露,保障网站的安全与可用性。关于Web应用防火墙的详细介绍请见:阿里云全新Web应用防火墙服务介绍

    阿里云web应用防火墙价格

    云盾Web应用防火墙目前提供包年包月购买方式。
    计费项:按套餐版本计算
    付费方式:预付费
    扣费周期:以用户购买当日起,按月/年售卖
    到期说明:当您购买的防护服务到期,Web应用防火墙配置为用户保留7天,7天内续费则继续防护,7天后,Web应用防火墙配置释放,服务不可用
    淘宝、支付宝都在用!WAF全部版本均支持HTTPS业务安全!
    支持非阿里云网站业务防护,网站需要在阿里云备案。旗舰版支持非80、443端口安全防护。

    套餐价格及详情

    Web应用防火墙目前线上售卖一共四个版本:增强版、高级版、企业版、旗舰版。
    推荐企业版:金融电商、政府等对安全性要求高的网站
    各版本除了QPS、访问控制规则条数等重要参数规格不同,其主要特点如下:
    增强版:支持HTTP(80端口)、HTTPS(443端口)基础的web攻击防护及cc防护。
    高级版:支持业务风控、HTTPS(443端口)的安全防护,CC高级防护、IP/URL/UA/Referer等高级访问控制。
    企业版:支持Web防护规则及CC防护规则专家定制、接口业务防刷。
    旗舰版:三地容灾、支持非80/443端口的HTTP/HTTPS业务防护,各种参数规格及功能可联系定制。

     套餐详情及价格表:

    产品参数具体描述增强版高级版企业版旗舰版
    产品价格单位:元/月8803,8809,80029,800(起)
    HTTP支持HTTP的业务防护支持支持支持支持
    HTTPS支持HTTPS的业务防护支持支持支持支持
    支持的防护端口支持防护的业务端口80/44380/44380/443非80\443的指定业务端口
    (联系我们)
    防护一级域名个数默认可防护的一级域名1111
    防护转发个数(二、多级域名)默认可防护的总转发个数
    支持泛域名
    10101010
    带宽阈值
    (源站服务器在阿里云)
    默认每秒的带宽阈值(Mbps)3050100200
    带宽阈值
    (源站服务器为非阿里云)
    默认每秒的带宽阈值(Mbps)5103050
    日常QPS阈值每秒的正常请求数阈值1,0002,0005,00010,000 (超出可定制)
    业务风控防护垃圾注册、刷库撞库、活动作弊、论坛灌水等业务防护不支持支持支持支持
    业务风控规则条数单域名支持的规则条数不支持51020
    业务风控防护接口能力每分钟请求调用量阈值不支持1003001000
    Web防护规则定制针对网站定制Web防护规则不支持不支持支持支持
    CC防护能力每秒的攻击请求数阈值10,00020,000100,000500,000(超出可定制)
    CC防护等级针对各种复杂CC攻击的防护效果默认宽松与严格防护,阻拦攻击特征明显的CC攻击可利用访问控制规则防护某些具有攻击特征的CC攻击专家定制防护规则,保障防护效果专家定制防护规则,保障防护效果
    自动封禁恶意IP针对攻击频繁的IP封禁一段时间不支持支持支持支持
    精准访问控制支持字段支持对HTTP常见字段的访问控制设置IP、URLIP、URL、User-Agent、RefererIP、URL、User-Agent、RefererIP、URL、User-Agent、Referer
    访问控制规则条数精准防护规则条数102050100(超出可定制)
    云外机房支持网站在阿里云外
    网站需要在阿里云接入备案
    支持支持支持支持
    Web应用基础防护防护如sql注入、命令执行等常见Web攻击支持支持支持支持
    0day漏洞补丁防御快速防护最新Web漏洞支持支持支持支持
    服务可用性防护服务部署的所在机房单机房单机房两地双活三城容灾
    回源IP个数同一个域名最多同时回源的IP10202020

    注:本价格表来源阿里云服务器价格表,如有变更恕不另行通知。

    展开全文
  • 1.EDAS简介企业级分布式应用服务(EDAS,Enterprise Distributed Application Service)是企业级互联网架构解决方案的核心产品,充分利用阿里现有资源管理和服务体系,引入中间件成熟的整套分布式计算框架(包括...
                                **
    

    企业及分布式应用EDAS使用操作

    **
    1.EDAS简介

    企业级分布式应用服务(EDAS,Enterprise Distributed Application Service)是企业级互联网架构解决方案的核心产品,充分利用阿里云现有资源管理和服务体系,引入中间件成熟的整套分布式计算框架(包括分布式服务化框架、服务治理、运维管控、链路追踪和稳定性组件等),以应用为中心,帮助企业级客户轻松构建并托管分布式应用服务体系。

    2.开始使用EDAS
    2.1.登录控制台
    从浏览器中访问EDAS控制台http://edas.console.aliyun.com ,进入如下页面:

    这里写图片描述

    2.2.安装Agent(EDAS与ECS之间的一座桥梁)
    进入资源管理-云服务器ECS 界面,点击右上角 “安装Agent” 按钮。
    这里写图片描述

    我们拷贝以下脚本在装有linux系统的ECS上运行以下脚本,来完成Agent的安装。
    注意:目前EDAS只支持centos6.5 64 bit 和 ali-linux 5.7 64 bit ,

    这里写图片描述
    可以看到,我们已经在ECS服务器上成功安装了Agent
    这里写图片描述

    2.3.创建应用
    进入 应用管理 界面,点击右上角 “创建应用” 按钮。

    这里写图片描述

    填写应用的相关信息
    这里写图片描述

    然后选择一个该区域的ECS,创建应用

    这里写图片描述
    我的应用已经创建成功,我们可以对这个应用进行各种管理
    这里写图片描述
    这里可以看到我们应用的所有信息
    应用实例目前的状态处于容器退出阶段,可以点击启动应用,当状态变成正常时,为可操作状态
    这里EDAS部署应用有五大状态,可以参考https://bbs.aliyun.com/read/269159.html?spm=5176.bbsl260.0.0.wlXGtQ

    这里写图片描述

    2.4.部署并启动应用
    点击部署应用
    这里写图片描述

    这里将我之前准备的一个war包上传至服务器,部署此应用

    这里写图片描述
    之后启动应用即可。
    应用可以访问成功了

    这里写图片描述
    3.应用监控
    日志记录:

    这里写图片描述
    CPU数据统计汇总

    这里写图片描述
    内存数据统计汇总
    这里写图片描述

    负载数据统计汇总

    这里写图片描述

    网络速度数据统计汇总
    这里写图片描述

    磁盘数据统计汇总
    这里写图片描述

    磁盘读写速度数据统计汇总
    这里写图片描述

    磁盘读写次数数据统计汇总

    这里写图片描述

    4.通知报警
    报警规则:我们可以在这里设置报警的规则,例如cpu使用率,负载,内存使用率…
    这里写图片描述

    报警联系人:
    这里写图片描述

    报警记录:
    这里写图片描述

    展开全文
  • 本次课程将以讲解和实战相结合的方式,向大家展示监控和可观测性...我们将带领大家在环境中部署Istio和微服务架构的范例程序guestbook,并通过Prometheus、Kiali和Jaeger来展示它们在service mesh中可观测性的能力。
  • 企业应用不要“晕

    千次阅读 2013-11-05 16:44:49
    企业应用不要“晕”我们迎来了互联网,全部业务都想放到互联网上,一则可以直接和客户、合作伙伴沟通,二则可以连通全球客户、合作伙伴,位在中国把生意做到全球。因而我们的互联网站点访问人多了、处理的业务多了...
    企业应用不要“晕云”
    


    我们迎来了互联网,全部业务都想放到互联网上,一则可以直接和客户、合作伙伴沟通,二则可以连通全球客户、合作伙伴,位在中国把生意做到全球。因而我们的互联网站点访问人多了、处理的业务多了、处理的数据也就多了,这样云计算和云存储的需求就都来了。


    我们过去拥有一台或几台电脑,后来我们拥有了服务器和客户端PC,后来我们拥有了N台服务器,再后来我们有了虚拟化可以把性能要求不大的应用放在一台物理主机上,后来我们的应用量大了了,需要做负载均衡集群部署分散部署了。我们就是这样一步步发展了过来。


    乃至发展到现状,我们的应用业务异常复杂了,我们的业务系统之间的关系也异常复杂了,我们的IT硬件基础设施也非常复杂了,于是我们不仅应用开发外包/应用集成对接开发外包,甚至业务流程梳理/项目管理/项目需求管理都外包给合作伙伴了,培训认证/试点应用/推广应用更不用说了,甚至我们的IT基础系统软硬件维护也被外包了,现在应用系统的配置变更/升级/异常跟踪修复/优化也都外包给合作伙伴了。因为确实太复杂了,我们自己要维护那得具备和软件公司同样的团队和能力,那我们的主业应该是什么呢?


    一、云存储/大数据


    现在业界流行几个词,一个是云计算,一个是大数据。我们的应用系统企业也是两部分构成的,一部分是应用系统代码,一部分是应用产生的数据。应用代码运行需要消耗CPU和内存,应用数据运行需要消耗存储IO和网络IO,现在应用数据为了快速存取更在内存数据存取上做文章。而业界研究云计算主要为了解决咱们应用代码运行性能的问题,而大数据主要解决应用数据存取性能的问题。


    大数据有很多种,有关系数据、BI多维分析数据、日志流水数据、OFFICE文档、照片数据、音频视频流媒体梳理,现在网状SNS关系出来了又多了一种网状关系数据。每种数据的访问特点都不一样,所以有了很多技术方案为了存储/访问/运算这些大量的各类数据。


    但是业界有个奇怪的点,就是各种数据都有新的技术涌出,但就是关系数据这方面的新技术不多。是现在的关系数据库已经满足人们的存取要求了么?为什么这么多人对应用系统的性能还抱怨这么多(大多都在关系数据的笛卡尔集合存取瓶颈和网络IO瓶颈上)。


    业界还真是这么认为的。目前的关系数据理论模型已经很成熟了,关系数据库产品经过过去几十年发展也已经很成熟了,处理性能很高了,10亿条记录都不在话下。如果是你性能不好,你肯定是数据架构设计烂、应用数据分布部署烂、数据库索引与SQL优化烂。


    业界认为真正的大数据不在企业内(一个企业最多10万人用电脑,就算频繁交易又能产生多少数据,那都是自以为是的大数据),单个企业之外的整个社会的数据才是真正的大数据。处理整个社会产生的数据,企业那点数据与之相比能算大数据么?


    咱们一般说企业经营管理。企业经营决定企业外扩,企业管理决定企业执行落地。企业经营决策更多需要企业外的数据,根据市场、政府、银行、竞争对手来决策经营策略。而管理决策更多需要企业内的数据。企业内的数据好获取,即使是自己的合作伙伴如供应商、仓储物流商、销售服务商的数据也都好通过利益联盟关系建立信息平台进行数据获取。但企业之外的数据企业就很难拿到了,这就是企业经营的最大痛点。没有真实、量化的信息可用于经营决策,只能通过私人关系一起吃饭聊天才能获取到一些相对真实的片段。现在各个企业包括政府部门都在信息化。各个组织的内部信息经过一定开放,数据互联,这就成为真正的大数据了。在这个大数据基础上进行决策,才能真正的理性的经营决策。但这样海量的大数据已经无法人为统计分析了,只能借助机器学习机器算法来辅助产生有价值的决策数据了。这样大的统计分析,这样大的数据,当然需要云计算技术、云存储技术、大数据挖掘技术了。


    二、云计算


    有人说了,我们的应用不仅数据存取有瓶颈,我们的应用代码运算服务器也有性能压力啊,访问人太多了,CPU和内存被顶死了。这有什么云计算方案啊。


    看了看现在的云计算技术,都是虚拟化技术。当然现在虚拟化已经在企业内部应用的很普遍了。但现在的业界云计算提供商也是虚拟技术,把一台物理服务器劈成多个虚拟机。大家都在这个层面琢磨,乃至现在出了一个应用层虚拟机技术叫Docker(过去咱们都是操作系统层面的深度虚拟机太重型)。


    为啥人们都发展虚拟化这类云技术,而不是真正大规模分布协调集群运算的云技术呢?


    这是人们认为在架构设计级别可以更省成本的解决这个问题。研发一个门户,各个应用都做到分散部署,都集成进门户中,访问时路由过去就行,所有应用无须放到一台超级服务器上,所有应用也无须分布在一台由N台物理服务器聚合虚拟成的超级服务器上。况且又有IP负载均衡方案、自动化部署升级工具,一个应用多份部署在N台服务器上都可以做到很好的代码同步管理和分流访问。


    三、总结


    我们现在企业应用需要云计算/大数据存取的新前沿技术吗?不需要。即使我们自己开展电子商务/自己做SNS,又能有多少数据和访问人数呢?即使我们访问社会化数据(如淘宝商品/百度地图),我们自己需要的数据又能有多大呢?


    但是虚拟化云虚拟主机和云数据存储(本质是分布式数据存放),可以让软件应用放到上面,减少我们自己运维这些复杂的系统软硬件扩展/升级/安全/监控/优化的难度,保证应用的基础稳固/问题及时发现及时解决。这是托管应用方式在云计算时代对于企业应用的最大好处。













    展开全文
  • JEECG承接代码生成器、Online开发之后,再创新举,开辟云应用开发新时代,打造jeecg企业云应用生态圈
  • 这个围绕应用和微服务的 PaaS 平台,将为企业解决IT系统复杂、升级迭代慢、运维扩展性差、海量用户支撑能力薄弱、数据孤岛等一系列难题,帮助传统企业快速构建面向互联网亿万用户的大规模分布式架构,降低企业IT成本...
  • IT应用和下一代企业的关系

    万次阅读 2014-04-03 11:38:06
    IT应用和下一代企业的关系一、IT应用和现在IT的优劣势对比1、安全:从技术安全角度来...而我们现在IT,很多企业的IT还是以局域网C/S应用为主,虽然也有不少企业应用了B/S应用,但都重重包围在VPN/U盾/域用户/指定IP
  • 本文将介绍Oracle集成Agent的基础架构,所包含的组件,和如何连接与OP应用
  • 利用UAP云平台实现应用弹性部署用友软件股份有限公司郭瑞升2014年01月15日...企业云计算分阶段需求阶段I阶段II阶段III现有应用迁移到云平台基于应用优化与重构实时应用/物联网资源虚拟化动态基础架构IT资源整合和...
  • 传统的中小企业应用中,使用oracle的系统占比较多。迁移到环境mysql数据库的情况下,需要考虑诸多因素,可用性、效率等。针对阿里上的系统迁移情况来看,中小企业为主,迁移的应用数量比较大,所用技术五花八门...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 243,318
精华内容 97,327
关键字:

云表企业应用平台