• 关于

    大型系统网络架构

    的搜索结果

问题

基于大数据的全球电商系统架构性能优化【精品问答集锦】

本期请来了阿里巴巴速卖通技术总监郭东白(阿白)直播分享基于大数据的全球电商系统架构性能优化 阿里巴巴速卖通技术总监。主要从事云计算和互联网电商领域的研究。有十六年大型软件系统研发和架构经验,对跨大洲、高可用、高流量服务端软件架构和研发有深...
管理贝贝 2019-12-01 20:28:14 29317 浏览量 回答数 13

回答

1,架构师是什么?要想往架构师的方向发展首先要知道架构师是什么?架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。一个架构师得需要足够的想像力,能把各种目标需求进行不同维度的扩展,为目标客户提供更为全面的需求清单。架构师在软件开发的整个过程中起着很重要的作用。说的详细一些,架构师就是确认和评估系统需求,给出开发规范,搭建系统实现的核心构架,并澄清技术细节、扫清主要难点的技术人员。主要着眼于系统的“技术实现”。2,架构师的任务架构师的主要任务不是从事具体的软件程序的编写,而是从事更高层次的开发构架工作。他必须对开发技术非常了解,并且需要有良好的组织管理能力。可以这样说,一个架构师工作的好坏决定了整个软件开发项目的成败。在成为Java架构师之前,应当先成为Java工程师。熟练使用各种框架,并知道它们实现的原理。jvm虚拟机原理、调优,懂得jvm能让你写出性能更好的代码;池技术,什么对象池,连接池,线程池……Java反射技术,写框架必备的技术,遇到有严重的性能问题,替代方案java字节码技术;nio,没什么好说的,值得注意的是"直接内存"的特点,使用场景;java多线程同步异步;java各种集合对象的实现原理,了解这些可以让你在解决问题时选择合适的数据结构,高效的解决问题,比如hashmap的实现原理,好多五年以上经验的人都弄不清楚,还有为什扩容时有性能问题?不弄清楚这些原理,就写不出高效的代码,还会认为自己做的很对;总之一句话,越基础的东西越重要,很多人认为自己会用它们写代码了,其实仅仅是知道如何调用api而已,离会用还差的远。如果你立志做架构,首先打好基础,从最底层开始。然后发展到各种技术和语言,什么都要懂两点,要全面且不肤浅。为什么不是懂一点?你要看得透彻,必须尽量深入一些。别人懂一点,你要做架构师,必须再多懂一点。比如你发现golang很流行,别人可能写一个helloworld就说自己玩过golang,但你至少要尝试写一个完整的应用。不肯下苦功,如何高人一头?另外你要非常深入地了解至少一门语言,如果你的目标是java,就学到极致,作为敲门砖,先吃饱了才能谈理想。3,架构师都是从码农过来的而Java学到极致势必涉及到设计模式,算法和数据结构,多线程,文件及网络IO,数据库及ORM,不一而足。这些概念放之一切语言都适用。先精一门,为全面且不肤浅打基础。另外就是向有经验的架构师学习,和小伙伴们讨论辩论争论。其实最重要的能力就是不断学习。在思考新的技术是否能更好地解决你们遇到的问题之前,你首先得知道并了解新的技术。架构师都是从码农过来的,媳妇熬成婆。千万不要成为不写代码的架构师,有些公司专门产不写技术的架构师。所谓架构师,只是功底深厚的程序员而已。个人认为应该扎扎实实学习基础知识,学习各种规范,架构,需要广泛的知识面,懂的东西越多视野越开阔,设计的东西当然会越好越全面。成为架构师需要时间的积累的,不但要知其然还要知其所以然。平时的一点一滴你感觉不到特别用处,但某天你会发现所有东西都没有白学的。4,架构师知识体系下面是我总结多年经验开发的架构师知识体系一、分布式架构架构分布式的英文( Distributed computing 分布式计算技术)的应用和工具,成熟目前的技术包括 J2EE,CORBA 和 .NET(DCOM),这些技术牵扯的内容非常广,相关的书籍也非常多。本文不介绍这些技术的内容,也没有涉及这些技术的细节,只是从各种分布式系统平台产生的背景和在软件开发中应用的情况来探讨它们的主要异同。分布式系统是一个古老而宽泛的话题,而近几年因为“大数据”概念的兴起,又焕发出了新的青春与活力。除此之外,分布式系统也是一门理论模型与工程技法。并重的学科内容相比于机器学习这样的研究方向,学习分布式系统的同学往往会感觉:“入门容易,深入难”的确,学习分布式系统几乎不需要太多数学知识。分布式系统是一个复杂且宽泛的研究领域,学习一两门在线课程,看一两本书可能都是不能完全覆盖其所有内容的。总的来说,分布式系统要做的任务就是把多台机器有机的组合,连接起来,让其协同完成一件任务,可以是计算任务,也可以是存储任务。如果一定要给近些年的分布式系统研究做一个分类的话,我个人认为大概可以包括三大部分:分布式存储系统分布式计算系统分布式管理系统二、微服务当前微服务很热,大家都号称在使用微服务架构,但究竟什么是微服务架构?微服务架构是不是发展趋势?对于这些问题,我们都缺乏清楚的认识。为解决单体架构下的各种问题,微服务架构应运而生。与其构建一个臃肿庞大,难以驯服的怪兽,还不如及早将服务拆分。微服务的核心思想便是服务拆分与解耦,降低复杂性。微服务强调将功能合理拆解,尽可能保证每个服务的功能单一,按照单一责任原则(Single Responsibility Principle)明确角色。将各个服务做轻,从而做到灵活,可复用,亦可根据各个服务自身资源需求,单独布署,单独作横向扩展。微服务架构(Microservice Architecture)是一种架构概念,旨在通过将功能分解到各个离散的服务中以实现对解决方案的解耦。你可以将其看作是在架构层次而非获取服务的类上应用很多 SOLID 原则。微服务架构是个很有趣的概念,它的主要作用是将功能分解到离散的各个服务当中,从而降低系统的耦合性,并提供更加灵活的服务支持。概念:把一个大型的单个应用程序和服务拆分为数个甚至数十个的支持微服务,它可扩展单个组件而不是整个的应用程序堆栈,从而满足服务等级协议。定义:围绕业务领域组件来创建应用,这些应用可独立地进行开发,管理和迭代在分散的组件中使用云架构和平台式部署,管理和服务功能,使产品交付变得更加简单。本质:用一些功能比较明确,业务比较精练的服务去解决更大,更实际的问题。三、源码分析从字面意义上来讲,源文件的英文指一个文件,指源代码的集合。源代码则是一组具有特定意义的可以实现特定功能的字符(程序开发代码)。源码分析是一种临界知识,掌握了这种临界知识,能不变应万变,源码分析对于很多人来说很枯燥,生涩难懂。源码阅读,我觉得最核心有三点:技术基础+强烈的求知欲+耐心。我认为是阅读源码的最核心驱动力我见到绝大多数程序员,对学习的态度,基本上就是这几个层次(很偏激哦):1,只关注项目本身,不懂就百度一下。2,除了做好项目,还会阅读和项目有关的技术书籍,看维基百科。3,除了阅读和项目相关的书外,还会阅读IT行业的书,比如学的Java的时,还会去了解函数语言,如LISP。4,找一些开源项目看看,大量试用第三方框架,还会写写演示。5,阅读基础框架,J2EE 规范,调试服务器内核。大多数程序都是第1种,到第5种不光需要浓厚的兴趣,还需要勇气:?我能读懂吗其实,你能够读懂的耐心,真的很重要。因为你极少看到阅读源码的指导性文章或书籍,也没有人要求或建议你读。你读的过程中经常会卡住,而一卡主可能就陷进了迷宫这时,你需要做的,可能是暂时中断一下,再从外围看看它:如API结构,框架的设计图。四、工具使用工欲善其事必先利其器,工具对 Java 的的程序员的重要性不言而喻现在有很多库,实用工具和程序任的 Java 的开发人员选择。下图列出的工具都是程序员必不可少的工具五、性能优化不管是应付前端面试还是改进产品体验,性能优化都是躲不开的话题。优化的目的是让用户有“快”的感受,那如何让用户感受到快呢?加载速度真的很快,用户打开输入网址按下回车立即看到了页面加载速度并没有变快,但用户感觉你的网站很快性能优化取决于多个因素,包括垃圾收集,虚拟机和底层操作系统(OS)设置。有多个工具可供开发人员进行分析和优化时使用,你可以通过阅读爪哇工具的源代码优化和分析来学习和使用它们。必须要明白的是,没有两个应用程序可以使用相同的优化方式,也没有完美的优化的 Java 应用程序的参考路径。使用最佳实践并且坚持采用适当的方式处理性能优化。想要达到真正最高的性能优化,你作为一个 Java 的开发人员,需要对 Java 的虚拟机(JVM)和底层操作系统有正确的理解。性能优化,简而言之,就是在不影响系统运行正确性的前提下,使之运行地更快,完成特定功能所需的时间更短。性能问题永远是永恒的主题之一,而优化则更需要技巧。Java程序员如何学习才能快速入门并精通呢?当真正开始学习的时候难免不知道从哪入手,导致效率低下影响继续学习的信心。但最重要的是不知道哪些技术需要重点掌握,学习时频繁踩坑,最终浪费大量时间,所以有一套实用的视频课程用来跟着学习是非常有必要的。为了让学习变得轻松、高效,今天给大家免费分享一套阿里架构师传授的一套教学资源。帮助大家在成为架构师的道路上披荆斩棘。这套视频课程详细讲解了(Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化、分布式架构)等这些成为架构师必备的内容!而且还把框架需要用到的各种程序进行了打包,根据基础视频可以让你轻松搭建分布式框架环境,像在企业生产环境一样进行学习和实践。
auto_answer 2019-12-02 01:51:27 0 浏览量 回答数 0

问题

存储虚拟化和服务器虚拟化紧密相关

  存储虚拟化和服务器虚拟化紧密相关   服务器虚拟化技术对企业IT运营发挥着积极的影响。服务器虚拟化技术为企业带来的利益开创云总结为两个方面:一是通过对物理服务器和遗留存储平台的整合,提高了现有硬件和软件的利用...
ayaaidandan2 2019-12-01 21:37:36 7345 浏览量 回答数 0

问题

客户案例分享——云络科技

云络科技 云络科技成立于2008年,是中国最早提供服务器管理及云计算服务的公司。是全球领先的OaaS运维即服务的倡导者和领跑者。公司总部位于上海,客户遍及亚洲和全球,专注于...
申木 2019-12-01 21:49:30 9891 浏览量 回答数 1

回答

在开始谈我对架构本质的理解之前,先谈谈对今天技术沙龙主题的个人见解,千万级规模的网站感觉数量级是非常大的,对这个数量级我们战略上 要重 视 它 , 战术上又 要 藐 视 它。先举个例子感受一下千万级到底是什么数量级?现在很流行的优步(Uber),从媒体公布的信息看,它每天接单量平均在百万左右, 假如每天有10个小时的服务时间,平均QPS只有30左右。对于一个后台服务器,单机的平均QPS可以到达800-1000,单独看写的业务量很简单 。为什么我们又不能说轻视它?第一,我们看它的数据存储,每天一百万的话,一年数据量的规模是多少?其次,刚才说的订单量,每一个订单要推送给附近的司机、司机要并发抢单,后面业务场景的访问量往往是前者的上百倍,轻松就超过上亿级别了。 今天我想从架构的本质谈起之后,希望大家理解在做一些建构设计的时候,它的出发点以及它解决的问题是什么。 架构,刚开始的解释是我从知乎上看到的。什么是架构?有人讲, 说架构并不是一 个很 悬 乎的 东西 , 实际 上就是一个架子 , 放一些 业务 和算法,跟我们的生活中的晾衣架很像。更抽象一点,说架构其 实 是 对 我 们 重复性业务 的抽象和我 们 未来 业务 拓展的前瞻,强调过去的经验和你对整个行业的预见。 我们要想做一个架构的话需要哪些能力?我觉得最重要的是架构师一个最重要的能力就是你要有 战 略分解能力。这个怎么来看呢: 第一,你必须要有抽象的能力,抽象的能力最基本就是去重,去重在整个架构中体现在方方面面,从定义一个函数,到定义一个类,到提供的一个服务,以及模板,背后都是要去重提高可复用率。 第二, 分类能力。做软件需要做对象的解耦,要定义对象的属性和方法,做分布式系统的时候要做服务的拆分和模块化,要定义服务的接口和规范。 第三, 算法(性能),它的价值体现在提升系统的性能,所有性能的提升,最终都会落到CPU,内存,IO和网络这4大块上。 这一页PPT举了一些例子来更深入的理解常见技术背后的架构理念。 第一个例子,在分布式系统我们会做 MySQL分 库 分表,我们要从不同的库和表中读取数据,这样的抽象最直观就是使用模板,因为绝大多数SQL语义是相同的,除了路由到哪个库哪个表,如果不使用Proxy中间件,模板就是性价比最高的方法。 第二看一下加速网络的CDN,它是做速度方面的性能提升,刚才我们也提到从CPU、内存、IO、网络四个方面来考虑,CDN本质上一个是做网络智能调度优化,另一个是多级缓存优化。 第三个看一下服务化,刚才已经提到了,各个大网站转型过程中一定会做服务化,其实它就是做抽象和做服务的拆分。第四个看一下消息队列,本质上还是做分类,只不过不是两个边际清晰的类,而是把两个边际不清晰的子系统通过队列解构并且异步化。新浪微博整体架构是什么样的 接下我们看一下微博整体架构,到一定量级的系统整个架构都会变成三层,客户端包括WEB、安卓和IOS,这里就不说了。接着还都会有一个接口层, 有三个主要作用: 第一个作用,要做 安全隔离,因为前端节点都是直接和用户交互,需要防范各种恶意攻击; 第二个还充当着一个 流量控制的作用,大家知道,在2014年春节的时候,微信红包,每分钟8亿多次的请求,其实真正到它后台的请求量,只有十万左右的数量级(这里的数据可能不准),剩余的流量在接口层就被挡住了; 第三,我们看对 PC 端和移 动 端的需求不一样的,所以我们可以进行拆分。接口层之后是后台,可以看到微博后台有三大块: 一个是 平台服 务, 第二, 搜索, 第三, 大数据。到了后台的各种服务其实都是处理的数据。 像平台的业务部门,做的就是 数据存储和读 取,对搜索来说做的是 数据的 检 索,对大数据来说是做的数据的 挖掘。微博其实和淘宝是很类似 微博其实和淘宝是很类似的。一般来说,第一代架构,基本上能支撑到用户到 百万 级别,到第二代架构基本能支撑到 千万 级别都没什么问题,当业务规模到 亿级别时,需要第三代的架构。 从 LAMP 的架构到面向服 务 的架构,有几个地方是非常难的,首先不可能在第一代基础上通过简单的修修补补满足用户量快速增长的,同时线上业务又不能停, 这是我们常说的 在 飞 机上 换 引擎的 问题。前两天我有一个朋友问我,说他在内部推行服务化的时候,把一个模块服务化做完了,其他部门就是不接。我建议在做服务化的时候,首先更多是偏向业务的梳理,同时要找准一个很好的切入点,既有架构和服务化上的提升,业务方也要有收益,比如提升性能或者降低维护成本同时升级过程要平滑,建议开始从原子化服务切入,比如基础的用户服务, 基础的短消息服务,基础的推送服务。 第二,就是可 以做无状 态 服 务,后面会详细讲,还有数据量大了后需要做数据Sharding,后面会将。 第三代 架构 要解决的 问题,就是用户量和业务趋于稳步增加(相对爆发期的指数级增长),更多考虑技术框架的稳定性, 提升系统整体的性能,降低成本,还有对整个系统监控的完善和升级。 大型网站的系统架构是如何演变的 我们通过通过数据看一下它的挑战,PV是在10亿级别,QPS在百万,数据量在千亿级别。我们可用性,就是SLA要求4个9,接口响应最多不能超过150毫秒,线上所有的故障必须得在5分钟内解决完。如果说5分钟没处理呢?那会影响你年终的绩效考核。2015年微博DAU已经过亿。我们系统有上百个微服务,每周会有两次的常规上线和不限次数的紧急上线。我们的挑战都一样,就是数据量,bigger and bigger,用户体验是faster and faster,业务是more and more。互联网业务更多是产品体验驱动, 技 术 在 产 品 体验上最有效的贡献 , 就是你的性能 越来越好 。 每次降低加载一个页面的时间,都可以间接的降低这个页面上用户的流失率。微博的技术挑战和正交分解法解析架构 下面看一下 第三代的 架构 图 以及 我 们 怎么用正交分解法 阐 述。 我们可以看到我们从两个维度,横轴和纵轴可以看到。 一个 维 度 是 水平的 分层 拆分,第二从垂直的维度会做拆分。水平的维度从接口层、到服务层到数据存储层。垂直怎么拆分,会用业务架构、技术架构、监控平台、服务治理等等来处理。我相信到第二代的时候很多架构已经有了业务架构和技术架构的拆分。我们看一下, 接口层有feed、用户关系、通讯接口;服务层,SOA里有基层服务、原子服务和组合服务,在微博我们只有原子服务和组合服务。原子服务不依赖于任何其他服务,组合服务由几个原子服务和自己的业务逻辑构建而成 ,资源层负责海量数据的存储(后面例子会详细讲)。技 术框架解决 独立于 业务 的海量高并发场景下的技术难题,由众多的技术组件共同构建而成 。在接口层,微博使用JERSY框架,帮助你做参数的解析,参数的验证,序列化和反序列化;资源层,主要是缓存、DB相关的各类组件,比如Cache组件和对象库组件。监 控平台和服 务 治理 , 完成系统服务的像素级监控,对分布式系统做提前诊断、预警以及治理。包含了SLA规则的制定、服务监控、服务调用链监控、流量监控、错误异常监控、线上灰度发布上线系统、线上扩容缩容调度系统等。 下面我们讲一下常见的设计原则。 第一个,首先是系统架构三个利器: 一个, 我 们 RPC 服 务组 件 (这里不讲了), 第二个,我们 消息中 间 件 。消息中间件起的作用:可以把两个模块之间的交互异步化,其次可以把不均匀请求流量输出为匀速的输出流量,所以说消息中间件 异步化 解耦 和流量削峰的利器。 第三个是配置管理,它是 代码级灰度发布以及 保障系统降级的利器。 第二个 , 无状态 , 接口 层 最重要的就是无状 态。我们在电商网站购物,在这个过程中很多情况下是有状态的,比如我浏览了哪些商品,为什么大家又常说接口层是无状态的,其实我们把状态从接口层剥离到了数据层。像用户在电商网站购物,选了几件商品,到了哪一步,接口无状态后,状态要么放在缓存中,要么放在数据库中, 其 实 它并不是没有状 态 , 只是在 这 个 过 程中我 们 要把一些有状 态 的 东 西抽离出来 到了数据层。 第三个, 数据 层 比服 务层 更需要 设计,这是一条非常重要的经验。对于服务层来说,可以拿PHP写,明天你可以拿JAVA来写,但是如果你的数据结构开始设计不合理,将来数据结构的改变会花费你数倍的代价,老的数据格式向新的数据格式迁移会让你痛不欲生,既有工作量上的,又有数据迁移跨越的时间周期,有一些甚至需要半年以上。 第四,物理结构与逻辑结构的映射,上一张图看到两个维度切成十二个区间,每个区间代表一个技术领域,这个可以看做我们的逻辑结构。另外,不论后台还是应用层的开发团队,一般都会分几个垂直的业务组加上一个基础技术架构组,这就是从物理组织架构到逻辑的技术架构的完美的映射,精细化团队分工,有利于提高沟通协作的效率 。 第五, www .sanhao.com 的访问过程,我们这个架构图里没有涉及到的,举个例子,比如当你在浏览器输入www.sanhao网址的时候,这个请求在接口层之前发生了什么?首先会查看你本机DNS以及DNS服务,查找域名对应的IP地址,然后发送HTTP请求过去。这个请求首先会到前端的VIP地址(公网服务IP地址),VIP之后还要经过负载均衡器(Nginx服务器),之后才到你的应用接口层。在接口层之前发生了这么多事,可能有用户报一个问题的时候,你通过在接口层查日志根本发现不了问题,原因就是问题可能发生在到达接口层之前了。 第六,我们说分布式系统,它最终的瓶颈会落在哪里呢?前端时间有一个网友跟我讨论的时候,说他们的系统遇到了一个瓶颈, 查遍了CPU,内存,网络,存储,都没有问题。我说你再查一遍,因为最终你不论用上千台服务器还是上万台服务器,最终系统出瓶颈的一定会落在某一台机(可能是叶子节点也可能是核心的节点),一定落在CPU、内存、存储和网络上,最后查出来问题出在一台服务器的网卡带宽上。微博多级双机房缓存架构 接下来我们看一下微博的Feed多级缓存。我们做业务的时候,经常很少做业务分析,技术大会上的分享又都偏向技术架构。其实大家更多的日常工作是需要花费更多时间在业务优化上。这张图是统计微博的信息流前几页的访问比例,像前三页占了97%,在做缓存设计的时候,我们最多只存最近的M条数据。 这里强调的就是做系统设计 要基于用 户 的 场 景 , 越细致越好 。举了一个例子,大家都会用电商,电商在双十一会做全国范围内的活动,他们做设计的时候也会考虑场景的,一个就是购物车,我曾经跟相关开发讨论过,购物车是在双十一之前用户的访问量非常大,就是不停地往里加商品。在真正到双十一那天他不会往购物车加东西了,但是他会频繁的浏览购物车。针对这个场景,活动之前重点设计优化购物车的写场景, 活动开始后优化购物车的读场景。 你看到的微博是由哪些部分聚合而成的呢?最右边的是Feed,就是微博所有关注的人,他们的微博所组成的。微博我们会按照时间顺序把所有关注人的顺序做一个排序。随着业务的发展,除了跟时间序相关的微博还有非时间序的微博,就是会有广告的要求,增加一些广告,还有粉丝头条,就是拿钱买的,热门微博,都会插在其中。分发控制,就是说和一些推荐相关的,我推荐一些相关的好友的微博,我推荐一些你可能没有读过的微博,我推荐一些其他类型的微博。 当然对非时序的微博和分发控制微博,实际会起多个并行的程序来读取,最后同步做统一的聚合。这里稍微分享一下, 从SNS社交领域来看,国内现在做的比较好的三个信息流: 微博 是 基于弱关系的媒体信息流 ; 朋友圈是基于 强 关系的信息流 ; 另外一个做的比 较 好的就是今日 头 条 , 它并不是基于关系来构建信息流 , 而是基于 兴趣和相关性的个性化推荐 信息流 。 信息流的聚合,体现在很多很多的产品之中,除了SNS,电商里也有信息流的聚合的影子。比如搜索一个商品后出来的列表页,它的信息流基本由几部分组成:第一,打广告的;第二个,做一些推荐,热门的商品,其次,才是关键字相关的搜索结果。 信息流 开始的时候 很 简单 , 但是到后期会 发现 , 你的 这 个流 如何做控制分发 , 非常复杂, 微博在最近一两年一直在做 这样 的工作。刚才我们是从业务上分析,那么技术上怎么解决高并发,高性能的问题?微博访问量很大的时候,底层存储是用MySQL数据库,当然也会有其他的。对于查询请求量大的时候,大家知道一定有缓存,可以复用可重用的计算结果。可以看到,发一条微博,我有很多粉丝,他们都会来看我发的内容,所以 微博是最适合使用 缓 存 的系统,微博的读写比例基本在几十比一。微博使用了 双 层缓 存,上面是L1,每个L1上都是一组(包含4-6台机器),左边的框相当于一个机房,右边又是一个机房。在这个系统中L1缓存所起的作用是什么? 首先,L1 缓 存增加整个系 统 的 QPS, 其次 以低成本灵活扩容的方式 增加 系统 的 带宽 。想象一个极端场景,只有一篇博文,但是它的访问量无限增长,其实我们不需要影响L2缓存,因为它的内容存储的量小,但它就是访问量大。这种场景下,你就需要使用L1来扩容提升QPS和带宽瓶颈。另外一个场景,就是L2级缓存发生作用,比如我有一千万个用户,去访问的是一百万个用户的微博 ,这个时候,他不只是说你的吞吐量和访问带宽,就是你要缓存的博文的内容也很多了,这个时候你要考虑缓存的容量, 第二 级缓 存更多的是从容量上来 规划,保证请求以较小的比例 穿透到 后端的 数据 库 中 ,根据你的用户模型你可以估出来,到底有百分之多少的请求不能穿透到DB, 评估这个容量之后,才能更好的评估DB需要多少库,需要承担多大的访问的压力。另外,我们看双机房的话,左边一个,右边一个。 两个机房是互 为 主 备 , 或者互 为热备 。如果两个用户在不同地域,他们访问两个不同机房的时候,假设用户从IDC1过来,因为就近原理,他会访问L1,没有的话才会跑到Master,当在IDC1没找到的时候才会跑到IDC2来找。同时有用户从IDC2访问,也会有请求从L1和Master返回或者到IDC1去查找。 IDC1 和 IDC2 ,两个机房都有全量的用户数据,同时在线提供服务,但是缓存查询又遵循最近访问原理。还有哪些多级缓存的例子呢?CDN是典型的多级缓存。CDN在国内各个地区做了很多节点,比如在杭州市部署一个节点时,在机房里肯定不止一台机器,那么对于一个地区来说,只有几台服务器到源站回源,其他节点都到这几台服务器回源即可,这么看CDN至少也有两级。Local Cache+ 分布式 缓 存,这也是常见的一种策略。有一种场景,分布式缓存并不适用, 比如 单 点 资 源 的爆发性峰值流量,这个时候使用Local Cache + 分布式缓存,Local Cache 在 应用 服 务 器 上用很小的 内存资源 挡住少量的 极端峰值流量,长尾的流量仍然访问分布式缓存,这样的Hybrid缓存架构通过复用众多的应用服务器节点,降低了系统的整体成本。 我们来看一下 Feed 的存 储 架构,微博的博文主要存在MySQL中。首先来看内容表,这个比较简单,每条内容一个索引,每天建一张表,其次看索引表,一共建了两级索引。首先想象一下用户场景,大部分用户刷微博的时候,看的是他关注所有人的微博,然后按时间来排序。仔细分析发现在这个场景下, 跟一个用户的自己的相关性很小了。所以在一级索引的时候会先根据关注的用户,取他们的前条微博ID,然后聚合排序。我们在做哈希(分库分表)的时候,同时考虑了按照UID哈希和按照时间维度。很业务和时间相关性很高的,今天的热点新闻,明天就没热度了,数据的冷热非常明显,这种场景就需要按照时间维度做分表,首先冷热数据做了分离(可以对冷热数据采用不同的存储方案来降低成本),其次, 很容止控制我数据库表的爆炸。像微博如果只按照用户维度区分,那么这个用户所有数据都在一张表里,这张表就是无限增长的,时间长了查询会越来越慢。二级索引,是我们里面一个比较特殊的场景,就是我要快速找到这个人所要发布的某一时段的微博时,通过二级索引快速定位。 分布式服务追踪系统 分布式追踪服务系统,当系统到千万级以后的时候,越来越庞杂,所解决的问题更偏向稳定性,性能和监控。刚才说用户只要有一个请求过来,你可以依赖你的服务RPC1、RPC2,你会发现RPC2又依赖RPC3、RPC4。分布式服务的时候一个痛点,就是说一个请求从用户过来之后,在后台不同的机器之间不停的调用并返回。 当你发现一个问题的时候,这些日志落在不同的机器上,你也不知道问题到底出在哪儿,各个服务之间互相隔离,互相之间没有建立关联。所以导致排查问题基本没有任何手段,就是出了问题没法儿解决。 我们要解决的问题,我们刚才说日志互相隔离,我们就要把它建立联系。建立联系我们就有一个请求ID,然后结合RPC框架, 服务治理功能。假设请求从客户端过来,其中包含一个ID 101,到服务A时仍然带有ID 101,然后调用RPC1的时候也会标识这是101 ,所以需要 一个唯一的 请求 ID 标识 递归迭代的传递到每一个 相关 节点。第二个,你做的时候,你不能说每个地方都加,对业务系统来说需要一个框架来完成这个工作, 这 个框架要 对业务 系 统 是最低侵入原 则 , 用 JAVA 的 话 就可以用 AOP,要做到零侵入的原则,就是对所有相关的中间件打点,从接口层组件(HTTP Client、HTTP Server)至到服务层组件(RPC Client、RPC Server),还有数据访问中间件的,这样业务系统只需要少量的配置信息就可以实现全链路监控 。为什么要用日志?服务化以后,每个服务可以用不同的开发语言, 考虑多种开发语言的兼容性 , 内部定 义标 准化的日志 是唯一且有效的办法。最后,如何构建基于GPS导航的路况监控?我们刚才讲分布式服务追踪。分布式服务追踪能解决的问题, 如果 单一用 户发现问题 后 , 可以通 过请 求 ID 快速找到 发 生 问题 的 节 点在什么,但是并没有解决如何发现问题。我们看现实中比较容易理解的道路监控,每辆车有GPS定位,我想看北京哪儿拥堵的时候,怎么做? 第一个 , 你肯定要知道每个 车 在什么位置,它走到哪儿了。其实可以说每个车上只要有一个标识,加上每一次流动的信息,就可以看到每个车流的位置和方向。 其次如何做 监 控和 报 警,我们怎么能了解道路的流量状况和负载,并及时报警。我们要定义这条街道多宽多高,单位时间可以通行多少辆车,这就是道路的容量。有了道路容量,再有道路的实时流量,我们就可以基于实习路况做预警? 对应于 分布式系 统 的话如何构建? 第一 , 你要 定义 每个服 务节 点它的 SLA A 是多少 ?SLA可以从系统的CPU占用率、内存占用率、磁盘占用率、QPS请求数等来定义,相当于定义系统的容量。 第二个 , 统计 线 上 动态 的流量,你要知道服务的平均QPS、最低QPS和最大QPS,有了流量和容量,就可以对系统做全面的监控和报警。 刚才讲的是理论,实际情况肯定比这个复杂。微博在春节的时候做许多活动,必须保障系统稳定,理论上你只要定义容量和流量就可以。但实际远远不行,为什么?有技术的因素,有人为的因素,因为不同的开发定义的流量和容量指标有主观性,很难全局量化标准,所以真正流量来了以后,你预先评估的系统瓶颈往往不正确。实际中我们在春节前主要采取了三个措施:第一,最简单的就是有降 级 的 预 案,流量超过系统容量后,先把哪些功能砍掉,需要有明确的优先级 。第二个, 线上全链路压测,就是把现在的流量放大到我们平常流量的五倍甚至十倍(比如下线一半的服务器,缩容而不是扩容),看看系统瓶颈最先发生在哪里。我们之前有一些例子,推测系统数据库会先出现瓶颈,但是实测发现是前端的程序先遇到瓶颈。第三,搭建在线 Docker 集群 , 所有业务共享备用的 Docker集群资源,这样可以极大的避免每个业务都预留资源,但是实际上流量没有增长造成的浪费。 总结 接下来说的是如何不停的学习和提升,这里以Java语言为例,首先, 一定要 理解 JAVA;第二步,JAVA完了以后,一定要 理 解 JVM;其次,还要 理解 操作系统;再次还是要了解一下 Design Pattern,这将告诉你怎么把过去的经验抽象沉淀供将来借鉴;还要学习 TCP/IP、 分布式系 统、数据结构和算法。
hiekay 2019-12-02 01:39:25 0 浏览量 回答数 0

回答

什么是轻量应用服务器 轻量应用服务器是面向单机应用场景的新一代计算服务,提供应用一键部署、一站式域名解析、网站发布、安全、运维、应用管理等服务。极大地优化了搭建简单应用的体验,降低了入门级用户使用云计算产品的门槛。 架构图 架构图 轻量应用服务器以套餐包年包月的形式售卖。 套餐资源包括: 由阿里云精选的常用应用镜像和系统镜像; 云服务器计算资源,包括基于 SSD 的存储资源、网络资源; 阿里云其他产品的基础功能(DNS,VPC 等)。 镜像 轻量应用服务器的镜像分应用镜像和系统镜像两种。 应用镜像 应用镜像包含如下部分: 应用及相关初始化数据; 应用所需运行环境; 底层操作系统。 应用镜像的优势 轻量应用服务器在安装应用镜像后,通过查阅应用的初始化信息,经过简单的配置后,可以直接开始使用应用,减少了应用的上传、安装环节,做到了应用的“开箱即用”。 系统镜像 系统镜像仅包含了初始操作系统,不含任何应用和环境信息。 系统镜像的优势 系统镜像是一个纯净的初始环境。用户可以安装所需的应用。适合对系统和应用环境配置比较了解的用户。 实例 轻量应用服务器的实例适用于小型Web应用、轻量应用等低负载应用场景,如果您需要选择其他的实例类型或者需要持续较高CPU性能负载的实例(如大型应用,视频编码等),请您使用阿里云ECS。 ECS 介绍,请参考 ECS实例规格族。 存储 为了提高性能,轻量应用服务器全系列均使用云盘 SSD 存储。 云盘介绍,请参考 云盘参数和性能测试方法。 网络 轻量应用服务器的网络是基于云服务器 ECS 的专有网络 VPC。 公网 每个轻量应用服务器配置一个公网 PublicIP(不能单独增加),并且配置了固定的公网带宽通信。 注意:专有网络的公网 PublicIP 是 NAT IP,无法通过命令行查询。 内网 同一个账号下的多个轻量应用服务器实例默认处于一个 VPC 内网环境下,多实例间的互联互通可以通过内网实现。内网带宽为万兆共享的带宽。但由于是共享网络,无法保证带宽速度不变。 集成阿里云产品 轻量应用服务器集成了多个阿里云产品的功能来帮助用户搭建和管理应用。主要有以下几类,后续会不断扩充。 域名解析。指定域名,并将域名指向到当前服务器的 IP 地址。 HTTPS 加密访问(CA 证书)。通过指定已经购买的 CA 证书,可以为 Web 服务配置 HTTPS 加密访问。 VPC 内网。同一个账号下的多个轻量应用服务器实例默认处于一个 VPC 内网环境下。
1934890530796658 2020-03-30 15:00:08 0 浏览量 回答数 0

问题

让我们一起来聊聊 Netty。

众所周知,构建高性能的现代互联网架构,我们一定离不开分布式系统,这些系统必定是反应式的。反应式的系统是一个比较新的概念,即消息驱动、弹性、极具适应性并且即时响应。构建这样的系统,定然离不开优秀的网络通信框架,其中 Netty 就是一款及其优...
千万别惹猫 2019-12-01 20:11:59 1967 浏览量 回答数 1

问题

达达O2O后台架构演进实践:从0到4000高并发请求背后的努力:报错

1、引言 达达创立于2014年5月,业务覆盖全国37个城市,拥有130万注册众包配送员,日均配送百万单,是全国领先的最后三公里物流配送平台。 达达的业务模式与滴滴以及Uber很相似...
kun坤 2020-06-09 15:20:48 4 浏览量 回答数 1

回答

Apache Cassandra数据库的优缺点有哪些? TAG标签: 数据库 Apache 优缺点 Cassandra 本文将超越众所周知的一些细节,探讨与 Cassandra 相关的不太明显的细节。您将检查 Cassandra 数据模型、存储模式设计、架构,以及与 Cassandra 相关的潜在惊喜。 在数据库历史文章 “What Goes Around Comes Around”中,Michal Stonebraker 详细描述了存储技术是如何随着时间的推移而发展的。实现关系模型之前,开发人员曾尝试过其他模型,比如层次图和有向图。值得注意的是,基于 SQL 的关系模型(即使到现在也仍然是事实上的标准)已经盛行了大约 30 年。鉴于计算机科学的短暂历史及其快速发展的步伐,这是一项非凡的成就。关系模型建立已久,以至于许多年来,解决方案架构师很容易为应用程序选择数据存储。他们的选择总是关系数据库。 诸如增加系统、移动设备、扩展的用户在线状态、云计算和多核系统的用户群之类的开发已经导致产生越来越多的大型系统。Google 和 Amazon 之类的高科技公司都是首批触及规模问题的公司。他们很快就发现关系数据库并不足以支持大型系统。 为了避免这些挑战,Google 和 Amazon 提出了两个可供选择的解决方案:Big Table 和 Dynamo,他们可以由此放松关系数据模型提供的保证,从而实现更高的可扩展性。Eric Brewer 的 “CAP Theorem”后来官方化了这些观察结果。它宣称,对于可扩展性系统,一致性、可用性和分区容错性都是权衡因素,因为根本不可能构建包含所有这些属性的系统。不久之后,根据 Google 和 Amazon 早期的工作,以及所获得的对可扩展性系统的理解,计划创建一种新的存储系统。这些系统被命名为 “NoSQL” 系统。该名称最初的意思是 “如果想缩放就不要使用 SQL”,后来被重新定义为 “不只是 SQL”,意思是说,除了基于 SQL 的解决方案外,还有其他的解决方案。 有许多 NoSQL 系统,而且每一个系统都缓和或改变了关系模型的某些方面。值得注意的是,没有一个 NoSQL 解决方案适用于所有的场景。每一个解决方案都优于关系模型,且针对一些用例子集进行了缩放。我的早期文章 “在 Data Storage Haystack 中为您的应用程序寻找正确的数据解决方案” 讨论了如何使应用程序需求和 NoSQL 解决方案相匹配。 Apache Cassandra是其中一个最早也是最广泛使用的 NoSQL 解决方案。本文详细介绍了 Cassandra,并指出了一些首次使用 Cassandra 时不容易发现的细节和复杂之处。 Apache Cassandra Cassandra 是一个 NoSQL 列族 (column family) 实现,使用由 Amazon Dynamo 引入的架构方面的特性来支持 Big Table 数据模型。Cassandra 的一些优势如下所示: 高度可扩展性和高度可用性,没有单点故障 NoSQL 列族实现 非常高的写入吞吐量和良好的读取吞吐量 类似 SQL 的查询语言(从 0.8 起),并通过二级索引支持搜索 可调节的一致性和对复制的支持 灵活的模式 这些优点很容易让人们推荐使用 Cassandra,但是,对于开发人员来说,至关重要的一点是要深入探究 Cassandra 的细节和复杂之处,从而掌握该程序的复杂性。 答案来源于网络
养狐狸的猫 2019-12-02 02:19:37 0 浏览量 回答数 0

回答

http接口是在接口不多、系统与系统交互较少的情况下,解决信息孤岛初期常使用的一种通信手段;优点就是简单、直接、开发方便。利用现成的http协议进行传输。但是如果是一个大型的网站,内部子系统较多、接口非常多的情况下,RPC框架的好处就显示出来了,首先就是长链接,不必每次通信都要像http一样去3次握手什么的,减少了网络开销;其次就是RPC框架一般都有注册中心,有丰富的监控管理;发布、下线接口、动态扩展等,对调用方来说是无感知、统一化的操作。第三个来说就是安全性。最后就是最近流行的服务化架构、服务化治理,RPC框架是一个强力的支撑。 socket只是一个简单的网络通信方式,只是创建通信双方的通信通道,而要实现rpc的功能,还需要对其进行封装,以实现更多的功能。 RPC一般配合netty框架、spring自定义注解来编写轻量级框架,其实netty内部是封装了socket的,较新的jdk的IO一般是NIO,即非阻塞IO,在高并发网站中,RPC的优势会很明显
剑曼红尘 2020-03-15 15:30:21 0 浏览量 回答数 0

回答

ReJava应用云上中间件如何选择     平时我们做系统常用tomcat服务器,所以也比较熟悉。对于需要用到ejb等分布式的技术的系统,通常会用到weblogic服务器和jboss服务器,那么这些服务器之间到底有什么差别,我们的系统最好部署在什么服务器上呢?下面来详细分析一下。 tomcat服务器:     tomcat服务器占用资源少,稳定且免费。是一个轻量级的服务器,主要是应用于中小型项目 ,当并发访问的用户比较少时,可以选用tomcat服务器。tomcat服务器是运行jsp和servlet的很好的容器,但是它不支持EJB等。项目在tomcat中的部署很方便。 weblogic服务器:     而相比之下,weblogic服务器则功能更强大了一些,它属于应用级服务器,它不尽支持jsp和servlet,而且还支持更多的java的规范。 他用于开发,集成,部署和管理大型的分布式web应用,网络应用和数据库应用。这种大型的服务器有着自己独特的优势,即标准领先(它的标准包括ejb,jsb,jms,jdbc,xml和wml),扩展性无限(它的体系架构具有高扩展性,主要包括哭户籍连接的共享,资源pooling以及动态网页和ejb组件集群),快速开发(凭借对ejb和jsp的支持,以及其对servlet组件的架构体系,可加速部署应用),部署灵活,可靠等。但是一般的系统部署基本不会用到它,因为一般非基于ejb等的分布式开发项目,仅仅用tomcat即可满足我们的需求,所以无需动用重量级的weblogic。 jboss服务器:     jboss是一个基于j2ee的开放源码应用服务器,它也是免费的。它是一个管理ejb的容器,jboss核心服务仅支持ejb服务器,所以是不包括jsp和servlet的web容器。当然了,它可以和tomcat等进行绑定使用来同时支持jsp,servlet以及ejb的规范。jboss有一个典型的特点:当有servlet的系统调用到jboss里面的ejb时不经过网络,因为jboss和web服务器在同一个java虚拟机中运行,这可以大大提高运行效率和安全性。      站在技术支持的角度一句话来概括这三个服务器的话:即weblogic相当于tomcat和jboss结合在一起使用(因为weblogic支持servlet和jsp以及ejb,而tomcat仅支持servlet和jsp,jboss仅支持ejb)
programmer 2019-12-02 00:33:50 0 浏览量 回答数 0

回答

可参考这里( 可以单独购买弹性ip:  https://www.aliyun.com/product/eip) 最简单的负载均衡架构 如下架构示例图:  虽然这个架构图非常简陋,但是的确利用DNS服务器做了负载均衡,多数大型网站都是混合式的负载均衡方案,基本都不会少了DNS的负载均衡。可以使用dig命令看看qq.com和baidu.com,其中baidu.com有4条A记录,也就是通过DNS做了4个分支的负载均衡。 图中还存在单点服务的地方,譬如共享文件系统的服务器端只在”web应用1“存在,不过意义非常大。 在应用系统搭建初期就规划好共享文件的存储路径,为将来的扩展提供便利,也给代码编写提供了参考标准,避免后期再做调整。如果是租用云服务器提供商的服务器,将来直接使用对象存储服务、CDN都比较容易。 双备份的数据库体系,架构简单易维护,但可以在故障发生的时候最大程度保护数据。 双备份的web应用,可以给前线业务提供高保障的应用系统,发布新版本的时候,还可以很方便的把其中一台作为预发布环境,新版本内容发布和验证完毕后再更新另外一台应用,起码保证了50%的业务正常运行。 配置简单,管理简单 当然,这仅仅只适用于时效要求低、缺少管理人员的创业型min公司。 利用负载均衡应用来搭建负载均衡架构 如图:  负载均衡服务的实现方式 DNS负载均衡 基于DNS的负载均衡方案是最容易实施的,而且通常你也不用去管DNS服务器的性能和可用性,它的属主会关心这些问题。但是通常DNS服务器只是通过RR算法来均衡调度,因此,用户的在线信息需要管理好,也就是session数据需要在所有服务器间进行共享,不然用户的登陆状态会丢失。 反向代理负载均衡 基于反向代理服务器实施负载均衡应该是应用得最多的方式,反向代理服务工作在7层,通过转发http请求提供服务。目前几乎所有web容器都支持反向代理服务,如nginx。nginx可以根据实际需要定义负载均衡调度算法,权重,健康状态检测等参数。 默认情况下,nginx使用 round-robin 调度算法,并有健康状态检查和恢复主机的能力,另外还支持ip_hash,least_conn,sticky,不过有的需要安装额外的组件。 Http重定向负载均衡 http重定向方案可以说最个性化的负载均衡方案,因为几乎是代码级的工作,不同于反向代理,反向代理是转发http请求,而http重定向是web服务告诉用户的浏览器去访问另外一个url,可能是根据IP地址找到了更好的服务器,或者其他策略。例如从镜像下载文件,中国区用户可能会重定向到一个中国区的服务器上进行下载。这都是通过http协议中指定Location属性来实现的。 NAT负载均衡 也叫IP负载均衡,工作在7层网络结构里的第四层,通过对数据包中的IP地址和端口信息进行修改,从而打到负载均衡的效果。因为涉及的知识比较深,而且我也没有实践过,所以不深入写了。 在《构建高性能Web站点》一书中,还提到两种更高性能的方案,即直接路由、IP隧道,因为工作得更底层更接近硬件,所以性能会比上面的方式更高。 混合型负载均衡 在有些大型网络,由于多个服务器群内硬件设备、各自的规模、提供的服务等的差异,可以考虑给每个服务器群采用最合适的负载均衡方式,然后又在这多个服务器群间再一次负载均衡或群集起来以一个整体向外界提供服务(即把这多个服务器群当做一个新的服务器群),从而达到最佳的性能。 望采纳,谢谢🙏
元芳啊 2019-12-02 00:09:01 0 浏览量 回答数 0

问题

手淘、微博一直钟情的 Netty框架是个什么鬼?

众所周知,构建高性能的现代互联网架构,我们一定离不开分布式系统,这些系统必定是反应式的。反应式的系统是一个比较新的概念,即消息驱动、弹性、极具适应性并且即时响应。构建这样的系统...
努力酱 2019-12-01 22:00:09 2866 浏览量 回答数 0

回答

虽然现在有很多的人呼吁使用混合云,因其可以利用私有云与公有的好处。但混合云也不是完全没有缺点的,它仍旧包含了一些安全障碍,要谨记下面五个问题。 公有云提供商提供重要的资源,以确保其基础架构在终端用户需要时有效且可访问。尽管云提供商进了最大努力,问题仍不可避免。大量宣传的宕机事件突出了将应用运转在单一数据中心且没有在其他数据中心进行故障恢复的风险。云架构师需要跨数据中心的冗余来减缓单一数据中心宕机的影响。缺少冗余对于混合云来说可能是严重的安全风险,尤其是如果数据冗余备份没有跨数据中心分布。在数据中心之间转移虚拟机(VM)实例比在大型数据集之间容易的多。云架构师可以使用一个厂商的多个数据中心实现冗余,或者多个公共云厂商或者是混合云。同时可以用混合云改善业务连续性,因为这并不是实现这个模型的唯一原因。同时使用来自单一厂商的多个数据中心,你可以节省成本,达到减少类似风险的水平。 维护和证明混合云法规尊重从更加困难。你不但要确保你的公有云提供商和私有云提供商符合法规,而且你必须证明两个云之间的协调是顺从的。比如,如果你的企业处理支付卡数据,你可能能够证明你的内部系统和你的云提供商遵从支付卡行业数据安全标准(PaymentCardIndustryDataSecurityStandard(PCIDSS))。引入了混合云,你必须确保两个云之间的数据转移是受到保护的。此外,你还需要确保卡数据不会从一个私有云上的法规遵从数据中心转移到一个较少安全性的公有云存储系统。你内部系统使用的预防漏洞的方法可能不直接转化到公有云上。 你可能坚信你的公有云提供商能够始终如一的符合服务水平协议(SLA)中期望的详细说明,但是你的私有云是否有同样的SLA?如果没有,你可能需要基于两个云的期望创建SLA,很可能就是基于你自己的私有云了。在你的私有云的可用性和性能的显示工作负载下收集数据。集成公有云和私有云寻求潜在的问题都会破坏服务。例如,如果一个私有云的关键业务驱动在本地保持敏感和机密数据,然后你的SLA应该体现出在公有云中使用这些服务的限制性。 从业务角度,信息安全是管理管理风险的。云计算(尤其是混合云)使用新的应用程序接口(API),要求复杂的网络配置,并对传统的系统管理员的知识和能力范围造成挑战。这些因素引入了新型的威胁。云计算并不比内部基础架构一样安全,但是混合云是个复杂的系统,管理员在管理上有限的经验,可能就造成了风险。 现有的安全控制,像身份认证、授权和身份认证管理需要在公有云和私有云中共同工作。整合这些安全协议,你只能选择其一:在两个云中复制控制并保持安全数据同步,或者使用身份认证管理服务,提供单一的服务运转在云端。在计划和时间阶段分配足够的时间,以便解决这些相当复杂的整合问题。
问问小秘 2019-12-02 03:00:17 0 浏览量 回答数 0

问题

微服务开发的 10 个最佳实践

1. 领域驱动设计: 开发微服务的首要挑战是将大型、复杂的应用程序分割成小型、自主、独立的可部署模块。如果微服务没有以正确的方式进行分割,将会出现紧耦合的微服务,这些微服务将具有单体架构的所有缺点...
游客pklijor6gytpx 2020-01-03 14:59:12 147 浏览量 回答数 1

回答

根据性能分类,云盘包含以下几类产品: ESSD云盘:基于新一代分布式块存储架构的超高性能云盘产品,结合25GE网络和RDMA技术,单盘可提供高达100万的随机读写能力和更低的单路时延能力。更多详情,请参见ESSD云盘。 建议在大型OLTP数据库、NoSQL数据库和ELK分布式日志等场景中使用。 SSD云盘:具备稳定的高随机读写性能、高可靠性的高性能云盘产品。 建议在I/O密集型应用、中小型关系数据库和NoSQL数据库等场景中使用。 高效云盘:具备高性价比、中等随机读写性能、高可靠性的云盘产品。 建议在开发与测试业务和系统盘等场景中使用。 普通云盘:属于上一代云盘产品,已经逐步停止售卖。
爱吃鱼的程序员 2020-12-28 12:06:30 0 浏览量 回答数 0

问题

学术界关于HBase在物联网/车联网/互联网/金融/高能物理等八大场景的理论研究

转载自:http://www.hbase.group/article/2 引言 HBase在互联网领域有广泛的应用,比如:互联网的消息系统的存储、订单的存储、搜索原材料的存储、用户画像数据的存储...
pandacats 2019-12-18 16:06:18 1 浏览量 回答数 0

问题

为什么要进行系统拆分?如何进行系统拆分?拆分后不用 dubbo 可以吗?【Java问答学堂】46期

面试题 为什么要进行系统拆分?如何进行系统拆分?拆分后不用 dubbo 可以吗? 面试官心理分析 从这个问题开始就进行分布式系统环节了,现在出去面试分布式都成标配了,...
剑曼红尘 2020-06-29 16:39:00 6 浏览量 回答数 1

问题

如何基于 dubbo 进行服务治理、服务降级、失败重试以及超时重试?【Java问答学堂】51期

面试题 如何基于 dubbo 进行服务治理、服务降级、失败重试以及超时重试? 面试官心理分析 服务治理,这个问题如果问你,其实就是看看你有没有服务治理的思想,因为这个是做过复杂微...
剑曼红尘 2020-07-06 11:19:50 0 浏览量 回答数 0

问题

【教程免费下载】  开源容器云OpenShift:构建基于Kubernetes的企业应用云平台

Preface?前  言 云起之时开源有道 我仍然记得,在2000年年初,国内软件开发领域最热门的操作系统、语言、开发工具、数据库等基本上都是大型商业公司的产品。那时Linux已经存在,但是还不算主...
沉默术士 2019-12-01 22:07:59 3222 浏览量 回答数 1

问题

网站技术职位之我见:报错

文章出处:http://blog.helosa.org/2010/07/16/website-job.html 搭建一个网站,需要很多职能的人加在一起,如策划、美工、技术等。小时候,这...
kun坤 2020-06-09 13:55:57 0 浏览量 回答数 1

问题

Java开发工程师必备技能

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

问题

Node.js 应该处于技术架构中的哪个位置?

Node.js 从 2009 年出世到现在,使用 Node.js 开发的构建工具改变了前端们的开发流程,已经是大部分前端开发者电脑上必装的 JavaScript Runtime 了。那它作为一门后端语言ÿ...
李博 bluemind 2019-12-01 21:47:42 2961 浏览量 回答数 0

问题

详解阿里云企业办公解决方案,开启办公“轻”时代

通过阿里云的会议无线投屏、云桌面、云AP三大企业级方案,阿里云能够为企业办公提供云时代的新一代解决方案。 三款产品分别应对了在企业应用中常见的几个高频场景:会议,办公桌面,网络...
琴瑟 2019-12-01 21:36:27 2149 浏览量 回答数 0

问题

你需要的是持续的服务改进

IT 正在变得越来越重要,作为公司运作链条上的一环,公司治理框架要将自己的业务目标、业务框架向 IT 传递。IT不再与基础建设和业务发展关联脱节,而是要紧密联系在一起的。 因此,有效...
sunny夏筱 2019-12-01 21:41:32 7450 浏览量 回答数 3

问题

阿里云的产品都是干嘛的

首先给大家推荐一个好链接,大家看了就知道:https://dwz.cn/dR4mHFaw 最近正好对这些产品做过总结,我来介绍一下阿里云主要的产品及功能: ECS (Elastic C...
游客bnlxddh3fwntw 2020-04-24 21:38:46 320 浏览量 回答数 1

问题

400余份阿里珍贵技术资料限时免费下载(持续更新中)? 400 报错

400余份阿里珍贵技术资料限时免费下载(持续更新中)? 400 报错 400余份阿里珍贵技术资料限时免费下载(持续更新中)   2017年,你是否有一个小目标&#x...
爱吃鱼的程序员 2020-05-31 13:00:37 0 浏览量 回答数 0

回答

微服务 (MicroServices) 架构是当前互联网业界的一个技术热点,圈里有不少同行朋友当前有计划在各自公司开展微服务化体系建设,他们都有相同的疑问:一个微服务架构有哪些技术关注点 (technical concerns)?需要哪些基础框架或组件来支持微服务架构?这些框架或组件该如何选型?笔者之前在两家大型互联网公司参与和主导过大型服务化体系和框架建设,同时在这块也投入了很多时间去学习和研究,有一些经验和学习心得,可以和大家一起分享。 服务注册、发现、负载均衡和健康检查和单块 (Monolithic) 架构不同,微服务架构是由一系列职责单一的细粒度服务构成的分布式网状结构,服务之间通过轻量机制进行通信,这时候必然引入一个服务注册发现问题,也就是说服务提供方要注册通告服务地址,服务的调用方要能发现目标服务,同时服务提供方一般以集群方式提供服务,也就引入了负载均衡和健康检查问题。根据负载均衡 LB 所在位置的不同,目前主要的服务注册、发现和负载均衡方案有三种: 第一种是集中式 LB 方案,如下图 Fig 1,在服务消费者和服务提供者之间有一个独立的 LB,LB 通常是专门的硬件设备如 F5,或者基于软件如 LVS,HAproxy 等实现。LB 上有所有服务的地址映射表,通常由运维配置注册,当服务消费方调用某个目标服务时,它向 LB 发起请求,由 LB 以某种策略(比如 Round-Robin)做负载均衡后将请求转发到目标服务。LB 一般具备健康检查能力,能自动摘除不健康的服务实例。服务消费方如何发现 LB 呢?通常的做法是通过 DNS,运维人员为服务配置一个 DNS 域名,这个域名指向 LB。 Fig 1, 集中式 LB 方案 集中式 LB 方案实现简单,在 LB 上也容易做集中式的访问控制,这一方案目前还是业界主流。集中式 LB 的主要问题是单点问题,所有服务调用流量都经过 LB,当服务数量和调用量大的时候,LB 容易成为瓶颈,且一旦 LB 发生故障对整个系统的影响是灾难性的。另外,LB 在服务消费方和服务提供方之间增加了一跳 (hop),有一定性能开销。 第二种是进程内 LB 方案,针对集中式 LB 的不足,进程内 LB 方案将 LB 的功能以库的形式集成到服务消费方进程里头,该方案也被称为软负载 (Soft Load Balancing) 或者客户端负载方案,下图 Fig 2 展示了这种方案的工作原理。这一方案需要一个服务注册表 (Service Registry) 配合支持服务自注册和自发现,服务提供方启动时,首先将服务地址注册到服务注册表(同时定期报心跳到服务注册表以表明服务的存活状态,相当于健康检查),服务消费方要访问某个服务时,它通过内置的 LB 组件向服务注册表查询(同时缓存并定期刷新)目标服务地址列表,然后以某种负载均衡策略选择一个目标服务地址,最后向目标服务发起请求。这一方案对服务注册表的可用性 (Availability) 要求很高,一般采用能满足高可用分布式一致的组件(例如 Zookeeper, Consul, Etcd 等)来实现。 Fig 2, 进程内 LB 方案 进程内 LB 方案是一种分布式方案,LB 和服务发现能力被分散到每一个服务消费者的进程内部,同时服务消费方和服务提供方之间是直接调用,没有额外开销,性能比较好。但是,该方案以客户库 (Client Library) 的方式集成到服务调用方进程里头,如果企业内有多种不同的语言栈,就要配合开发多种不同的客户端,有一定的研发和维护成本。另外,一旦客户端跟随服务调用方发布到生产环境中,后续如果要对客户库进行升级,势必要求服务调用方修改代码并重新发布,所以该方案的升级推广有不小的阻力。 进程内 LB 的案例是 Netflix 的开源服务框架,对应的组件分别是:Eureka 服务注册表,Karyon 服务端框架支持服务自注册和健康检查,Ribbon 客户端框架支持服务自发现和软路由。另外,阿里开源的服务框架 Dubbo 也是采用类似机制。 第三种是主机独立 LB 进程方案,该方案是针对第二种方案的不足而提出的一种折中方案,原理和第二种方案基本类似,不同之处是,他将 LB 和服务发现功能从进程内移出来,变成主机上的一个独立进程,主机上的一个或者多个服务要访问目标服务时,他们都通过同一主机上的独立 LB 进程做服务发现和负载均衡,见下图 Fig 3。 Fig 3 主机独立 LB 进程方案 该方案也是一种分布式方案,没有单点问题,一个 LB 进程挂了只影响该主机上的服务调用方,服务调用方和 LB 之间是进程内调用,性能好,同时,该方案还简化了服务调用方,不需要为不同语言开发客户库,LB 的升级不需要服务调用方改代码。该方案的不足是部署较复杂,环节多,出错调试排查问题不方便。 该方案的典型案例是 Airbnb 的 SmartStack 服务发现框架,对应组件分别是:Zookeeper 作为服务注册表,Nerve 独立进程负责服务注册和健康检查,Synapse/HAproxy 独立进程负责服务发现和负载均衡。Google 最新推出的基于容器的 PaaS 平台 Kubernetes,其内部服务发现采用类似的机制。 服务前端路由微服务除了内部相互之间调用和通信之外,最终要以某种方式暴露出去,才能让外界系统(例如客户的浏览器、移动设备等等)访问到,这就涉及服务的前端路由,对应的组件是服务网关 (Service Gateway),见图 Fig 4,网关是连接企业内部和外部系统的一道门,有如下关键作用: 服务反向路由,网关要负责将外部请求反向路由到内部具体的微服务,这样虽然企业内部是复杂的分布式微服务结构,但是外部系统从网关上看到的就像是一个统一的完整服务,网关屏蔽了后台服务的复杂性,同时也屏蔽了后台服务的升级和变化。安全认证和防爬虫,所有外部请求必须经过网关,网关可以集中对访问进行安全控制,比如用户认证和授权,同时还可以分析访问模式实现防爬虫功能,网关是连接企业内外系统的安全之门。限流和容错,在流量高峰期,网关可以限制流量,保护后台系统不被大流量冲垮,在内部系统出现故障时,网关可以集中做容错,保持外部良好的用户体验。监控,网关可以集中监控访问量,调用延迟,错误计数和访问模式,为后端的性能优化或者扩容提供数据支持。日志,网关可以收集所有的访问日志,进入后台系统做进一步分析。 Fig 4, 服务网关 除以上基本能力外,网关还可以实现线上引流,线上压测,线上调试 (Surgical debugging),金丝雀测试 (Canary Testing),数据中心双活 (Active-Active HA) 等高级功能。 网关通常工作在 7 层,有一定的计算逻辑,一般以集群方式部署,前置 LB 进行负载均衡。 开源的网关组件有 Netflix 的 Zuul,特点是动态可热部署的过滤器 (filter) 机制,其它如 HAproxy,Nginx 等都可以扩展作为网关使用。 在介绍过服务注册表和网关等组件之后,我们可以通过一个简化的微服务架构图 (Fig 5) 来更加直观地展示整个微服务体系内的服务注册发现和路由机制,该图假定采用进程内 LB 服务发现和负载均衡机制。在下图 Fig 5 的微服务架构中,服务简化为两层,后端通用服务(也称中间层服务 Middle Tier Service)和前端服务(也称边缘服务 Edge Service,前端服务的作用是对后端服务做必要的聚合和裁剪后暴露给外部不同的设备,如 PC,Pad 或者 Phone)。后端服务启动时会将地址信息注册到服务注册表,前端服务通过查询服务注册表就可以发现然后调用后端服务;前端服务启动时也会将地址信息注册到服务注册表,这样网关通过查询服务注册表就可以将请求路由到目标前端服务,这样整个微服务体系的服务自注册自发现和软路由就通过服务注册表和网关串联起来了。如果以面向对象设计模式的视角来看,网关类似 Proxy 代理或者 Façade 门面模式,而服务注册表和服务自注册自发现类似 IoC 依赖注入模式,微服务可以理解为基于网关代理和注册表 IoC 构建的分布式系统。 Fig 5, 简化的微服务架构图 服务容错当企业微服务化以后,服务之间会有错综复杂的依赖关系,例如,一个前端请求一般会依赖于多个后端服务,技术上称为 1 -> N 扇出 (见图 Fig 6)。在实际生产环境中,服务往往不是百分百可靠,服务可能会出错或者产生延迟,如果一个应用不能对其依赖的故障进行容错和隔离,那么该应用本身就处在被拖垮的风险中。在一个高流量的网站中,某个单一后端一旦发生延迟,可能在数秒内导致所有应用资源 (线程,队列等) 被耗尽,造成所谓的雪崩效应 (Cascading Failure,见图 Fig 7),严重时可致整个网站瘫痪。 Fig 6, 服务依赖 Fig 7, 高峰期单个服务延迟致雪崩效应 经过多年的探索和实践,业界在分布式服务容错一块探索出了一套有效的容错模式和最佳实践,主要包括: Fig 8, 弹性电路保护状态图 电路熔断器模式 (Circuit Breaker Patten), 该模式的原理类似于家里的电路熔断器,如果家里的电路发生短路,熔断器能够主动熔断电路,以避免灾难性损失。在分布式系统中应用电路熔断器模式后,当目标服务慢或者大量超时,调用方能够主动熔断,以防止服务被进一步拖垮;如果情况又好转了,电路又能自动恢复,这就是所谓的弹性容错,系统有自恢复能力。下图 Fig 8 是一个典型的具备弹性恢复能力的电路保护器状态图,正常状态下,电路处于关闭状态 (Closed),如果调用持续出错或者超时,电路被打开进入熔断状态 (Open),后续一段时间内的所有调用都会被拒绝 (Fail Fast),一段时间以后,保护器会尝试进入半熔断状态 (Half-Open),允许少量请求进来尝试,如果调用仍然失败,则回到熔断状态,如果调用成功,则回到电路闭合状态。舱壁隔离模式 (Bulkhead Isolation Pattern),顾名思义,该模式像舱壁一样对资源或失败单元进行隔离,如果一个船舱破了进水,只损失一个船舱,其它船舱可以不受影响 。线程隔离 (Thread Isolation) 就是舱壁隔离模式的一个例子,假定一个应用程序 A 调用了 Svc1/Svc2/Svc3 三个服务,且部署 A 的容器一共有 120 个工作线程,采用线程隔离机制,可以给对 Svc1/Svc2/Svc3 的调用各分配 40 个线程,当 Svc2 慢了,给 Svc2 分配的 40 个线程因慢而阻塞并最终耗尽,线程隔离可以保证给 Svc1/Svc3 分配的 80 个线程可以不受影响,如果没有这种隔离机制,当 Svc2 慢的时候,120 个工作线程会很快全部被对 Svc2 的调用吃光,整个应用程序会全部慢下来。限流 (Rate Limiting/Load Shedder),服务总有容量限制,没有限流机制的服务很容易在突发流量 (秒杀,双十一) 时被冲垮。限流通常指对服务限定并发访问量,比如单位时间只允许 100 个并发调用,对超过这个限制的请求要拒绝并回退。回退 (fallback),在熔断或者限流发生的时候,应用程序的后续处理逻辑是什么?回退是系统的弹性恢复能力,常见的处理策略有,直接抛出异常,也称快速失败 (Fail Fast),也可以返回空值或缺省值,还可以返回备份数据,如果主服务熔断了,可以从备份服务获取数据。Netflix 将上述容错模式和最佳实践集成到一个称为 Hystrix 的开源组件中,凡是需要容错的依赖点 (服务,缓存,数据库访问等),开发人员只需要将调用封装在 Hystrix Command 里头,则相关调用就自动置于 Hystrix 的弹性容错保护之下。Hystrix 组件已经在 Netflix 经过多年运维验证,是 Netflix 微服务平台稳定性和弹性的基石,正逐渐被社区接受为标准容错组件。 服务框架微服务化以后,为了让业务开发人员专注于业务逻辑实现,避免冗余和重复劳动,规范研发提升效率,必然要将一些公共关注点推到框架层面。服务框架 (Fig 9) 主要封装公共关注点逻辑,包括: Fig 9, 服务框架 服务注册、发现、负载均衡和健康检查,假定采用进程内 LB 方案,那么服务自注册一般统一做在服务器端框架中,健康检查逻辑由具体业务服务定制,框架层提供调用健康检查逻辑的机制,服务发现和负载均衡则集成在服务客户端框架中。监控日志,框架一方面要记录重要的框架层日志、metrics 和调用链数据,还要将日志、metrics 等接口暴露出来,让业务层能根据需要记录业务日志数据。在运行环境中,所有日志数据一般集中落地到企业后台日志系统,做进一步分析和处理。REST/RPC 和序列化,框架层要支持将业务逻辑以 HTTP/REST 或者 RPC 方式暴露出来,HTTP/REST 是当前主流 API 暴露方式,在性能要求高的场合则可采用 Binary/RPC 方式。针对当前多样化的设备类型 (浏览器、普通 PC、无线设备等),框架层要支持可定制的序列化机制,例如,对浏览器,框架支持输出 Ajax 友好的 JSON 消息格式,而对无线设备上的 Native App,框架支持输出性能高的 Binary 消息格式。配置,除了支持普通配置文件方式的配置,框架层还可集成动态运行时配置,能够在运行时针对不同环境动态调整服务的参数和配置。限流和容错,框架集成限流容错组件,能够在运行时自动限流和容错,保护服务,如果进一步和动态配置相结合,还可以实现动态限流和熔断。管理接口,框架集成管理接口,一方面可以在线查看框架和服务内部状态,同时还可以动态调整内部状态,对调试、监控和管理能提供快速反馈。Spring Boot 微框架的 Actuator 模块就是一个强大的管理接口。统一错误处理,对于框架层和服务的内部异常,如果框架层能够统一处理并记录日志,对服务监控和快速问题定位有很大帮助。安全,安全和访问控制逻辑可以在框架层统一进行封装,可做成插件形式,具体业务服务根据需要加载相关安全插件。文档自动生成,文档的书写和同步一直是一个痛点,框架层如果能支持文档的自动生成和同步,会给使用 API 的开发和测试人员带来极大便利。Swagger 是一种流行 Restful API 的文档方案。当前业界比较成熟的微服务框架有 Netflix 的 Karyon/Ribbon,Spring 的 Spring Boot/Cloud,阿里的 Dubbo 等。 运行期配置管理服务一般有很多依赖配置,例如访问数据库有连接字符串配置,连接池大小和连接超时配置,这些配置在不同环境 (开发 / 测试 / 生产) 一般不同,比如生产环境需要配连接池,而开发测试环境可能不配,另外有些参数配置在运行期可能还要动态调整,例如,运行时根据流量状况动态调整限流和熔断阀值。目前比较常见的做法是搭建一个运行时配置中心支持微服务的动态配置,简化架构如下图 (Fig 10): Fig 10, 服务配置中心 动态配置存放在集中的配置服务器上,用户通过管理界面配置和调整服务配置,具体服务通过定期拉 (Scheduled Pull) 的方式或者服务器推 (Server-side Push) 的方式更新动态配置,拉方式比较可靠,但会有延迟同时有无效网络开销 (假设配置不常更新),服务器推方式能及时更新配置,但是实现较复杂,一般在服务和配置服务器之间要建立长连接。配置中心还要解决配置的版本控制和审计问题,对于大规模服务化环境,配置中心还要考虑分布式和高可用问题。 配置中心比较成熟的开源方案有百度的 Disconf,360 的 QConf,Spring 的 Cloud Config 和阿里的 Diamond 等。 Netflix 的微服务框架Netflix 是一家成功实践微服务架构的互联网公司,几年前,Netflix 就把它的几乎整个微服务框架栈开源贡献给了社区,这些框架和组件包括: Eureka: 服务注册发现框架Zuul: 服务网关Karyon: 服务端框架Ribbon: 客户端框架Hystrix: 服务容错组件Archaius: 服务配置组件Servo: Metrics 组件Blitz4j: 日志组件下图 Fig 11 展示了基于这些组件构建的一个微服务框架体系,来自 recipes-rss。 Fig 11, 基于 Netflix 开源组件的微服务框架 Netflix 的开源框架组件已经在 Netflix 的大规模分布式微服务环境中经过多年的生产实战验证,正逐步被社区接受为构造微服务框架的标准组件。Pivotal 去年推出的 Spring Cloud 开源产品,主要是基于对 Netflix 开源组件的进一步封装,方便 Spring 开发人员构建微服务基础框架。对于一些打算构建微服务框架体系的公司来说,充分利用或参考借鉴 Netflix 的开源微服务组件 (或 Spring Cloud),在此基础上进行必要的企业定制,无疑是通向微服务架构的捷径。 原文地址:https://www.infoq.cn/article/basis-frameworkto-implement-micro-service#anch130564%20%EF%BC%8C
auto_answer 2019-12-02 01:55:22 0 浏览量 回答数 0

回答

设计微服务五个建议:1.它不会与其他服务共享数据库表2.它拥有最少量的数据库表3.它设计为有状态的或无状态的4.其数据可用性需求5.这是真相的唯一来源避免任意规则在设计和创建微服务时,不要陷入使用任意规则的陷阱。如果你阅读了足够多的建议,你会遇到下面的一些规则。虽然吸引人,但这些并不都是划分微服务边界的正确方法。如下:1.“微服务应该有X行代码”让我们弄清楚一件事。对于微服务中有多少行代码没有限制。微服务不会因为你写了几行额外的代码而突然变成单体巨石。关键是确保服务中的代码具有很高的凝聚力(稍后会详细介绍)。2.“将每个函数变成微服务”如果一个函数是根据三个输入值计算出某些东西,并返回一个结果,那么这个函数就是一个微服务吗?这个函数是否是一个可单独部署的应用程序吗?其实真的取决于函数是什么以及它如何服务于整个系统。其他任意规则包括那些不考虑整个上下文的规则,例如团队的经验,DevOps容量,服务在做什么以及数据的可用性需求等。精心设计的服务的特点如果您已阅读过有关微服务的文章,毫无疑问,您会发现有关设计良好的服务的建议。简而言之:高凝聚力和松散耦合。如果你不熟悉这些概念,有很多关于这些概念的文章。虽然合理的建议,但这些概念是相当抽象的。 我已经和数十位CTO就这个话题进行了交流,向他们学习他们如何划分微服务界限,下面为你们提供了一些潜在的特性。特性#1:它不会与其他服务共享数据库表当设计一个微服务时,如果你有多个引用同一个表的服务,这是一个红色警告,因为它可能意味着你的数据库是耦合的来源。“每个服务都应该有自己的表[并且]不应共享数据库表。” - Darby Frey,Lead Honestly共同创始人这实际上是关于服务与数据的关系,这正是Elastic Swiftype SRE的负责人Oleksiy Kovrin告诉我的:“我们在开发新服务时使用的主要基本原则之一是它们不应该跨越数据库边界。每项服务都应该依靠自己的一套底层数据存储。这使我们能够集中访问控制,审计日志记录,缓存逻辑等等,“他说。Kovyrin继续解释说,如果数据库表的一部分“与数据集的其余部分没有或很少有关系,这是一个强烈的信号,即组件可能可以被隔离到一个单独的API或单独的服务中。”特性#2:它具有最少量的数据库表正如第1章所提到的,微服务的理想尺寸应该足够小,但不能过小一点。每个服务的数据库表的数量也是一样。Scaylr工程负责人Steven Czerwinski在接受采访时向我解释说,Scaylr的甜蜜点是“一个服务 + 一个或两个数据库表”。特点#3:它有设计为有状态或无状态在设计微服务时,您需要问自己是否需要访问数据库,或者它是否将成为处理TB数据(如电子邮件或日志)的无状态服务。“我们通过定义服务的输入和输出来定义服务的边界。有时服务是网络API,但它也可能是一个处理输入文件并在数据库中生成记录的过程(这是我们的日志处理服务的情况)“ - Julien Lemoine要清楚这个前沿,它会导致更好的设计服务。特点#4:它的数据可用性需求被考虑在内在设计微服务时,您需要记住哪些服务将依赖于这项新服务,以及如果数据不可用,对系统的影响是什么。考虑到这一点,您可以为此服务正确设计数据备份和恢复系统。 当与Steven Czerwinski谈话时,他提到他们的关键客户行空间映射数据由于其重要性而以不同方式复制和分离到不同分区。“而每个分片信息,都是在自己的小分区中。 如果所在分区宕机,那么就没有备份可用,但它只影响5%的客户,而不是100%的客户,“Czerwinski解释说。特点#5:这是一个真理的单一来源要牢记的最后一个特点是设计一个服务,使其成为系统中某件事情的唯一真理来源。举例来说,当您从电子商务网站订购某物品时,会生成订单ID。此订单ID可供其他服务用于查询订单服务以获取有关订单的完整信息。使用pub / sub概念,在服务之间传递的数据应该是订单ID,而不是订单本身的属性/信息。只有订单服务具有完整的信息,并且是给定订单的唯一真实来源。考虑更大的团队对于大型系统而言,在确定服务边界时,组织架构考虑将发挥作用。有两点需要注意:独立发布时间表和不同的上线时间的重要性。Cloud66首席执行官Khash Sajadi表示:“我们所见过的最成功的微服务实施要么基于软件设计原则,例如基于领域驱动设计、面向服务架构SOA或反映组织方式的架构。“所以对于支付团队来说,”Sajadi继续说道,“他们有支付服务或信用卡验证服务,这是他们向外界提供的服务。这主要是关于向外界提供更多服务的业务部门。““[亚马逊CEO:杰夫贝佐斯]提出了'两个比萨饼'的规则 - 一个团队不能多到两个披萨饼还不够他们吃的地步。” - Iron.io首席技术官Travis Reeder亚马逊是拥有多个团队的大型组织的完美典范。正如在API推荐人发表的一篇文章中提到的,杰夫贝佐斯向所有员工发布了一份授权通知他们,公司内的每个团队都必须通过API进行沟通。任何不会的人将被解雇。这样,所有的数据和功能都通过接口暴露出来。贝佐斯还设法让每个团队解耦,定义他们的资源,并通过API使其可用。亚马逊总是自底而上从头开始建立一个系统。这可以让公司内的每个团队成为彼此的合作伙伴。我与Iron.io的首席技术官Travis Reeder谈到了贝佐斯的内部计划。“杰夫贝佐斯强制所有team都必须建立API来与其他team进行沟通,他也提出了'两个披萨'规则,一个团队不能多到两个披萨饼还不够他们吃的地步。”他说。“我认为这同样适用于这样情况:当一个小团队在开发、管理和生产方面开始变得笨拙或开始变慢,这说明这个团队可能已经太大了,“Reeder告诉我。如何判断服务是否太小,或许没有正确定义在微服务系统的测试和实施阶段,需要牢记下面两条出现现象。要注意的第一个现象是服务之间的任何过度依赖。如果两个服务不断地互相调用,那么这已经是一个强烈的耦合信号,他们如果并成一个服务可能更好。第二个现象:建立服务的开销超过了让其独立的好处。在这种情况下不如合并成一个服务。Darby Frey解释说:“每个应用程序需要将其日志汇总到某处并需要进行监控。您需要设置报警。然后需要有标准的响应操作程序,并在事情中断时运行。你必须管理SSH的访问权限。为了让应用程序正常运行,必须准备大量基础设施支持。“
wangccsy 2019-12-02 01:46:40 0 浏览量 回答数 0

问题

VPC网络架构助力媒体数字化转型

在2018云栖大会-南京峰会上,阿里云技术专家胡茂庐讲述了阿里云网络架构VPC的概念,并对比经典网络详细分析了VPC及其产品的核心优势,以及讲述了全球网络的实现方式。在最后由新华报业传媒集团技术装备...
福利达人 2019-12-01 21:09:15 3511 浏览量 回答数 0
阿里云企业服务平台 陈四清的老板信息查询 上海奇点人才服务相关的云产品 爱迪商标注册信息 安徽华轩堂药业的公司信息查询 小程序定制 上海微企信息技术相关的云产品 国内短信套餐包 ECS云服务器安全配置相关的云产品 天籁阁商标注册信息 开发者问答 阿里云建站 自然场景识别相关的云产品 万网 小程序开发制作 视频内容分析 视频集锦 代理记账服务 北京芙蓉天下的公司信息查询