第四周作业
一个典型的大型互联网应用系统使用了哪些技术方案和手段,主要解决什么问题?请列举描述。
CDN: CDN的基本原理是广泛采用各种缓存服务器,将这些缓存服务器分布到用户访问相对集中的地区或网络中,在用户访问网站时,利用全局负载技术将用户的访问指向距离最近的工作正常的缓存服务器上,由缓存服务器直接响应用户请求。
反向代理服务器: 反向代理对外都是透明的,访问者者并不知道自己访问的是一个代理。因为客户端不需要任何配置就可以访问。例如常用的nginx
反向代理是一种可以集中地调用内部服务,并提供统一接口给公共客户的 Web 服务器。
反向代理实际运行方式是指以代理服务器来接受连接请求,然后将请求转发给内部网络上的服务器,并将从服务器上得到的结果返回给请求连接的客户端,此时代理服务器对外就表现为一个服务器。
反向代理的作用:
保证内网的安全。隐藏后端服务器的信息,屏蔽黑名单中的 IP,限制每个客户端的连接数。
提高可扩展性和灵活性。客户端只能看到反向代理服务器的 IP,这使你可以增减服务器或者修改它们的配置。
缓存。直接返回命中的缓存结果
静态内容直接返回:HTML/CSS/JS图片视频等等
负载均衡:
其含义就是指将负载(工作任务)进行平衡、分摊到多个操作单元上进行运行,例如LVS F5 ngnix
消息队列:
1. 解耦
在项目启动之初来预测将来项目会碰到什么需求,是极其困难的。消息队列在处理过程中间插入了一个隐含的、基于数据的接口层,两边的处理过程都要实现这一接口。这允许你独立的扩展或修改两边的处理过程,只要确保它们遵守同样的接口约束。
2. 冗余
有时在处理数据的时候处理过程会失败。除非数据被持久化,否则将永远丢失。消息队列把数据进行持久化直到它们已经被完全处理,通过这一方式规避了数据丢失风险。在被许多消息队列所采用的"插入-获取-删除"范式中,在把一个消息从队列中删除之前,需要你的处理过程明确的指出该消息已经被处理完毕,确保你的数据被安全的保存直到你使用完毕。
3. 扩展性
因为消息队列解耦了你的处理过程,所以增大消息入队和处理的频率是很容易的;只要另外增加处理过程即可。不需要改变代码、不需要调节参数。扩展就像调大电力按钮一样简单。
4. 灵活性 & 峰值处理能力
当你的应用上了Hacker News的首页,你将发现访问流量攀升到一个不同寻常的水平。在访问量剧增的情况下,你的应用仍然需要继续发挥作用,但是这样的突发流量并不常见;如果为以能处理这类峰值访问为标准来投入资源随时待命无疑是巨大的浪费。使用消息队列能够使关键组件顶住增长的访问压力,而不是因为超出负荷的请求而完全崩溃。
5. 可恢复性
当体系的一部分组件失效,不会影响到整个系统。消息队列降低了进程间的耦合度,所以即使一个处理消息的进程挂掉,加入队列中的消息仍然可以在系统恢复后被处理。而这种允许重试或者延后处理请求的能力通常是造就一个略感不便的用户和一个沮丧透顶的用户之间的区别。
6. 送达保证
消息队列提供的冗余机制保证了消息能被实际的处理,只要一个进程读取了该队列即可。在此基础上,IronMQ提供了一个"只送达一次"保证。无论有多少进程在从队列中领取数据,每一个消息只能被处理一次。这之所以成为可能,是因为获取一个消息只是"预定"了这个消息,暂时把它移出了队列。除非客户端明确的表示已经处理完了这个消息,否则这个消息会被放回队列中去,在一段可配置的时间之后可再次被处理。
7.排序保证
在许多情况下,数据处理的顺序都很重要。消息队列本来就是排序的,并且能保证数据会按照特定的顺序来处理。IronMO保证消息浆糊通过FIFO(先进先出)的顺序来处理,因此消息在队列中的位置就是从队列中检索他们的位置。
8.缓冲
在任何重要的系统中,都会有需要不同的处理时间的元素。例如,加载一张图片比应用过滤器花费更少的时间。消息队列通过一个缓冲层来帮助任务最高效率的执行--写入队列的处理会尽可能的快速,而不受从队列读的预备处理的约束。该缓冲有助于控制和优化数据流经过系统的速度。
9. 理解数据流
在一个分布式系统里,要得到一个关于用户操作会用多长时间及其原因的总体印象,是个巨大的挑战。消息系列通过消息被处理的频率,来方便的辅助确定那些表现不佳的处理过程或领域,这些地方的数据流都不够优化。
10. 异步通信
很多时候,你不想也不需要立即处理消息。消息队列提供了异步处理机制,允许你把一个消息放入队列,但并不立即处理它。你想向队列中放入多少消息就放多少,然后在你乐意的时候再去处理它们。
微服务:
独立的可扩展性,每个微服务都可以独立进行横向或纵向扩展,根据业务实际增长情况来进行快速扩展;
独立的可升级性,每个微服务都可以独立进行服务升级、更新,不用依赖于其它服务,结合持续集成工具可以进行持续发布,开发人员就可以独立快速完成服务升级发布流程;
易维护性,每个微服务的代码均只专注于完成该单个业务范畴的事情,因此微服务项目代码数量将减少至IDE可以快速加载的大小,这样可以提高了代码的可读性,进而可以提高研发人员的生产效率;
语言无关性,研发人员可以选用自己最为熟悉的语言和框架来完成他们的微服务项目(当然,一般根据每个公司的实际技术栈需要来了),这样在面对新技术或新框架的选用时,微服务能够更好地进行快速响应;
故障和资源的隔离性,在系统中出现不好的资源操作行为时,例如内存泄露、数据库连接未关闭等情况,将仅仅只会影响单个微服务;
优化跨团队沟通,如果要完全实践微服务架构设计风格,研发团队势必会按照新的原则来进行划分,由之前的按照技能、职能划分的方式变为按照业务(单个微服务)来进行划分,如此这般团队里将有各个方向技能的研发人员,沟通效率上来说要优于之前按照技能进行划分的组织架构;
原生基于“云”的系统架构设计,基于微服务架构设计风格,我们能构建出来原生对于“云”具备超高友好度的系统,与常用容器工具如Docker能够很方便地结合,构建持续发布系统与IaaS、PaaS平台对接,使其能够方便的部署于各类“云”上,如公用云、私有云以及混合云。
中台:
1.快速响应业务,这也是中台最重要的一点。当今社会,什么都要求快,你做个系统用三年,人家三个月,你上线了,人家D轮都融完资了,还怎么打?业务部门经常遇见的问题是:市场变化了,我想改系统的东西,提需求要IT部门去改,要么告诉你不能改,要么告诉你要很久,等他做完了,时机早就过去了,做出来没意义了,这个时候你多希望这头提出需求,那头立刻就能上线,对,中台就是为这个而生的,中台的架构都是为前台的业务而生,是按业务而不是按功能区分模块或服务,这样就大大提供了业务的响应能力,而且中台一般是由无数个微服务构成,按业务线划分,每一个业务线都精进自己的产品不断的提高和增强,每个业务线都是自己领域的专家,这样能更快速的响应业务的需求,而不是系统的需求。
2.解决重复开发的问题。中台就是抽象出相同的业务,解决重复开发的问题。企业中经常遇见一个新业务就要把会员系统、积分系统、订单系统等等重复来一遍的事情,原因是新的业务和原来的系统不匹配,无法兼容。中台就是把这些共享的业务抽象共享,新的业务,只要考虑自己前端的问题就可以了,不用考虑中后台的事情,这些东西我们都给你解决了,你只要写个APP,新系统就上线了。
搜索引擎:
如ElasticSearch
1、Elasticsearch的功能
(1)分布式的搜索引擎和数据分析引擎
搜索:百度,网站的站内搜索,IT系统的检索
数据分析:电商网站,最近7天牙膏这种商品销量排名前10的商家有哪些;新闻网站,最近1个月访问量排名前3的新闻版块是哪些
(2)全文检索,结构化检索,数据分析
全文检索:我想搜索商品名称包含牙膏的商品,select * from products where product_name like "%牙膏%"
结构化检索:我想搜索商品分类为日化用品的商品都有哪些,select * from products where category_id='日化用品'
部分匹配、自动完成、搜索纠错、搜索推荐
数据分析:我们分析每一个商品分类下有多少个商品,select categoryid,count(*) from products group by categoryid
(3)对海量数据进行近实时的处理
分布式:ES自动可以将海量数据分散到多台服务器上去存储和检索
海量数据的处理:分布式以后,就可以采用大量的服务器去存储和检索数据,自然而然就可以实现海量数据的处理了
近实时:检索个数据要花费1小时(这就不要近实时,离线批处理,batch-processing);在秒级别对数据进行搜索和分析
跟分布式/海量数据相反的:lucene,单机应用,只能在单台服务器上使用,最多只能处理单台服务器可以处理的数据量
Elasticsearch的特点
(1)可以作为一个大型分布式集群(数百台服务器)技术,处理PB级数据,服务大公司;也可以运行在单机上,服务小公司
(2)Elasticsearch不是什么新技术,主要是将全文检索、数据分析以及分布式技术,合并在了一起,才形成了独一无二的ES;lucene(全文检索),商用的数据分析软件(也是有的),分布式数据库(mycat)
(3)对用户而言,是开箱即用的,非常简单,作为中小型的应用,直接3分钟部署一下ES,就可以作为生产环境的系统来使用了,数据量不大,操作不是太复杂
(4)数据库的功能面对很多领域是不够用的(事务,还有各种联机事务型的操作);特殊的功能,比如全文检索,同义词处理,相关度排名,复杂数据分析,海量数据的近实时处理;Elasticsearch作为传统数据库的一个
分布式缓存和NoSql:
最常见的如Redis集群
一、为什么使用
解决应用服务器的cpu和内存压力
减少io的读操作,减轻io的压力
关系型数据库的扩展性不强,难以改变表结构
二、优点:
nosql数据库没有关联关系,数据结构简单,拓展表比较容易
nosql读取速度快,对较大数据处理快
三、适用场景:
数据高并发的读写
海量数据的读写
对扩展性要求高的数据
分布式文件系统:如FastDFS
一、fastdfs是什么
fastdfs是一款开源的轻量级的分布式文件系统
二、fastdfs能解决什么问题
分布式场景下的文件上传下载读取问题。分布式架构下的服务为了抗住高并发都会存在集群。但是在有集群(比如现在有服务器a、b、c)的情况下,如果用户本次登录被负载均衡调到服务器a了,此时他在服务器上上传了一张图片,然后他注销了。下一次登录的时候他又被负载均衡到另一台服务器b了,此时他想查看他上次上传的图片就看不到了。这就产生了数据不同步的问题,集群的存在带来了数据不同步的问题。
fastdfs可以解决这个问题。它由client,跟踪服务器tracker和存储服务器storage三部分构成。
拿分布式架构下,用户上传图片的情景举例。fastdfs的工作过程是这样的:
用户向服务端发起一个上传图片的请求
服务端接收到用户的请求,并作为client向fastdfs的跟踪服务器tracker发送上传请求。
tracker接收到client的请求,并根据一定的负载均衡策略,向client指定一个存储的地址,指定图片放到哪个组进行存储,并返回给服务端一个包含图片存储地址信息的对象。
(补充)每个组里都有两个storage储存服务器,一个是主storage,另外一个是备份的storage。图片被存到主storage后会被拷贝一份带到备份storage中。
但是这个拷贝的过程有可能会出现文件损坏,但坑爹的是fastfds的底层并没有一个针对文件同步时做校验的机制,所以为了确保你自己做的系统的可用性,
分布式数据库:如Mycat数据库中间件
一、Mycat是什么
Mycat是一个开源的分布式数据库系统,是一个实现了 MySQL 协议的的 Server,前端用户可以把它看作是一个数据库代理,用 MySQL 客户端工具和命令行访问,而其后端可以用MySQL 原生(Native)协议与多个 MySQL 服务器通信,也可以用 JDBC 协议与大多数主流数据库服务器通信,其核心功能是分表分库,即将一个大表水平分割为 N 个小表,存储在后端 MySQL 服务器里或者其他数据库里。
Mycat 是一个近似等于 MySQL 的数据库服务器,但它本身并不存储数据,数据是在后端的 MySQL 上存储的,数据可靠性以及事务等都是 MySQL 保证的。你可以用连接 MySQL 的方式去连接 Mycat(除了端口不同,默认的 Mycat 端口是 8066 而非 MySQL 的 3306,因此需要在连接字符串上增加端口信息),大多数情况下,可以用你熟悉的对象映射框架使用 Mycat,但建议对于分片表,尽量使用基础的 SQL 语句,因为这样能达到最佳性能,特别是几千万甚至几百亿条记录的情况下。
二、Mycat的原理
Mycat 的原理并不复杂,复杂的是代码。Mycat 的原理中最重要的一个动词是“拦截”,它拦截了用户发送过来的 SQL 语句,首先对 SQL 语句做了一些特定的分析:如分片分析、路由分析、读写分离分析、缓存分析等,然后将此 SQL 发往后端的真实数据库,并将返回的结果做适当的处理,最终再返回给用户。
当 Mycat 收到一个 SQL 时,会先解析这个 SQL,查找涉及到的表,然后看此表的定义,如果有分片规则,则获取到 SQL 里分片字段的值,并匹配分片函数,得到该 SQL 对应的分片列表,然后将 SQL 发往这些分片去执行,最后收集和处理所有分片返回的结果数据,并输出到客户端。
三、Mycat应用场景
单纯的读写分离,此时配置最为简单,支持读写分离,主从切换;
分表分库,对于超过 1000 万的表进行分片,最大支持 1000 亿的单表分片;
多租户应用,每个应用一个库,但应用程序只连接 Mycat,从而不改造程序本身,实现多租户化;
报表系统,借助于 Mycat 的分表能力,处理大规模报表的统计;
替代 Hbase,分析大数据;
作为海量数据实时查询的一种简单有效方案,比如 100 亿条频繁查询的记录需要在 3 秒内查询出来结果,除了基于主键的查询,还可能存在范围查询或其他属性查询,此时 Mycat 可能是最简单有效的选择。
评论