大型网站技术架构(四)--核心架构要素 开启mac上印象笔记的代码块 大型网站技术架构(三)--架构模式 JDK8 stream toMap() java.lang.IllegalStateExcep

大型网站技术架构(四)--核心架构要素

 

做者:13
GitHub:https://github.com/ZHENFENG13
版权声明:本文为原创文章,未经容许不得转载。
此篇已收录至《大型网站技术架构:核心原理与案例分析》读书笔记系列,点击访问该目录获取完整内容。php

前言

所谓架构,一种通俗的说法就是“最高层次的规划,难以改变的决定”,这些规划和决定奠基了事物将来发展的方向和最终的蓝图。html

而软件架构即“有关软件总体结构与组件的抽象描述,用于指导大型软件系统各方面的设计”。java

通常来讲软件架构须要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素。git

1

性能

性能是网站架构设计的一个重要方面,任何软件架构设计方案都必须考虑可能带来的性能问题,也正由于性能问题几乎无处不在,因此优化网站性能的手段也很是多。github

  • 浏览器端:能够经过浏览器缓存、页面压缩传输、合理布局页面、减小Cookie传输等手段,甚至可使用CDN加速功能。
  • 应用服务器端:可使用服务器本地缓存和分布式缓存,也能够经过异步操做方式来加快响应,在高并发请求的状况下,能够将多台应用服务器组成一个集群共同对外服务,提升总体处理能力,改善性能。
  • 数据库服务器端:可用使用索引、缓存、SQL性能优化等手段,还可使用NoSQL数据库来优化数据模型、存储结构等。

衡量网站性能有一系列指标,重要的有响应时间、TPS、系统性能计数器等,经过这些指标以肯定系统设计是否达到目标。数据库

2

可用性

可用性即可以不间断提供服务的时间。几乎全部网站都承诺7×24小时可用,但事实上任何网站都不可能达到彻底的7×24,总会有一些故障时间,扣除这些故障时间,就是网站的可用时间。一些大型网站能够作到4个9以上的可用性,也就是99.99%。浏览器

网站高可用的主要手段就是冗余,应用部署在多台服务器上同时提供服务,数据存储在多台服务器上相互备份,任何一台服务器都不会影响应用的总体能够,一般的实现手段即把多台服务器经过负载均衡设备组成一个集群。缓存

衡量一个系统架构设计是否知足高可用的目标,就是假设系统中任何一台或者多台服务器宕机时,以及出现各类不可预期的问题时,系统总体是否依然可用。安全

3

伸缩性

大型网站须要面对大量用户的高并发访问和存储海量数据,网站经过集群的方式将多台服务器组成一个总体共同提供服务。所谓伸缩性是指经过不断向集群中加入服务器的手段来缓解不断总体上市用户并发访问压力和不断增加的数据存储需求。性能优化

衡量架构伸缩性的主要标准就是是否可用多台服务器构建集群,是否容易向集群中添加新的服务器。加入新的服务器后是否能够提供和原来的服务器无差异的服务。集群中可容纳的总服务器数量是否有限制。

4

扩展性

不一样于其余架构要素主要关注非功能性需求,网站的扩展性架构直接关注网站的功能需求。网站快速发展,功能不断扩展,如何设计网站的架构使其可以快速响应需求变化,是网站可扩展架构的主要目标。

衡量网站架构扩展性好坏的主要标准就是在网站增长新的业务产品时,是否能够实现对现有产品透明无影响,不一样产品之间是否不多耦合等。

网站可扩展架构的主要手段是事件驱动架构和分布式服务。

  • 事件驱动一般利用消息队列实现,经过这种方式将消息生产和处理逻辑分隔开。
  • 服务器服务则是将业务和可复用服务分离开来,经过分布式服务框架调用。新增长产品可用经过调用可复用的服务来实现自身的业务逻辑,而对现有产品没有任何影响。

5

安全性

互联网是开发的,任何人在任何地方均可以访问网站。网站的安全架构就是保护网站不受恶意访问和攻击,保护网站的重要数据不被窃取。

衡量网站安全架构的标准就是针对现存和潜在的各类攻击和窃密手段,是否有可靠的应对策略。

security

这个世界没有绝对的安全,正如没有绝对的自由同样,很遗憾,这个世界上没有固若金汤的网站安全架构,咱们只能天天打起百分百的精神,预防可能的漏洞或者攻击。

首发于个人我的博客,2017年5月18日。

我曾七次鄙视本身的灵魂:
第一次,当它本可进取时,却故做谦卑;
第二次,当它空虚时,用爱欲来填充;
第三次,在困难和容易之间,它选择了容易;
第四次,它犯了错,却借由别人也会犯错来宽慰本身;
第五次,它自由软弱,却把它认为是生命的坚韧;
第六次,当它鄙夷一张丑恶的嘴脸时,殊不知那正是本身面具中的一副;
第七次,它侧身于生活的污泥中虽不甘心,却又畏首畏尾。
 
 
 

开启mac上印象笔记的代码块

 

Mac 印象笔记左上角菜单栏:偏好设置-->软件更新-->开启代码块

(Preferences -> Software Update -> Enable code block)

如图:

Evernote

我曾七次鄙视本身的灵魂:
第一次,当它本可进取时,却故做谦卑;
第二次,当它空虚时,用爱欲来填充;
第三次,在困难和容易之间,它选择了容易;
第四次,它犯了错,却借由别人也会犯错来宽慰本身;
第五次,它自由软弱,却把它认为是生命的坚韧;
第六次,当它鄙夷一张丑恶的嘴脸时,殊不知那正是本身面具中的一副;
第七次,它侧身于生活的污泥中虽不甘心,却又畏首畏尾。
 
 
 

大型网站技术架构(三)--架构模式

 

做者:13
GitHub:https://github.com/ZHENFENG13
版权声明:本文为原创文章,未经容许不得转载。
此篇已收录至《大型网站技术架构:核心原理与案例分析》读书笔记系列,点击访问该目录获取完整内容。

前言

模式:每个模式描述了一个在咱们周围不断重复发生的问题及该问题解决方案的核心。这样,你就能一次又一次地使用该方案而没必要作重复工做。

网站架构模式:大型互联网公司在实践中提出了许多解决方案,以实现网站高性能、高可用、易伸缩、可扩展、安全等各类技术框架目标。这些解决方案又被更多网站重复使用,从而逐渐造成大型网站架构模式。

所谓网站架构模式即为了解决大型网站面临的高并发访问、海量数据、高可靠运行灯一系列问题与挑战,为此,在实践中提出了许多解决方案,以实现网站高性能、高可靠性、易伸缩、可扩展、安全等各类技术架构目标。

分层

分层是企业应用系统中最多见的一种架构模式,将系统在横向维度上切分红几个部分,每一个部分负责一部分相对简单并比较单一的职责,而后经过上层对下层的依赖和调度组成一个完整的系统。
ssm-demo结构图:

在网站的分层架构中,常见的为3层,即应用层、服务层、数据层。
应用层具体负责业务和视图的展现;服务层为应用层提供服务支持;数据库提供数据存储访问服务,如数据库、缓存、文件、搜索引擎等。
分层架构是逻辑上的,在物理部署上,三层架构能够部署在同一个物理机器上,可是随着网站业务的发展,必然须要对已经分层的模块分离部署,即三层结构分别部署在不一样的服务器上,是网站拥有更多的计算资源以应对愈来愈多的用户访问。

因此虽然分层架构模式最初的目的是规划软件清晰的逻辑结构以便于开发维护,但在网站的发展过程当中,分层结构对网站支持高并发向分布式方向的发展相当重要。

分隔

若是说分层是将软件在横向方面进行切分,那么分隔就是在纵向方面对软件进行切分。
网站越大,功能越复杂,服务和数据处理的种类也越多,将这些不一样的功能和服务分隔开来,包装成高内聚低耦合的模块单元,不只有助于软件的开发维护也便于不一样模块的分布式部署,提升网站的并发处理能力和功能扩展能力。
大型网站分隔的粒度可能会很小。好比在应用层,将不一样业务进行分隔,例如将购物、论坛、搜索、广告分隔成不一样的应用,有对立的团队负责,部署在不一样的服务器上。

分布式

对于大型网站,分层和分隔的一个主要目的是为了切分后的模块便于分布式部署,即将不一样模块部署在不一样的服务器上,经过远程调用协同工做。分布式意味着可使用更多的计算机完一样的工做,计算机越多,CPU、内存、存储资源就越多,能过处理的并发访问和数据量就越大,进而可以为更多的用户提供服务。
在网站应用中,经常使用的分布式方案有一下几种:

  • 分布式应用和服务:将分层和分隔后的应用和服务模块分布式部署,能够改善网站性能和并发性、加快开发和发布速度、减小数据库链接资源消耗。

  • 分布式静态资源:网站的静态资源如JS、CSS、Logo图片等资源对立分布式部署,并采用独立的域名,即人们常说的动静分离。静态资源分布式部署能够减轻应用服务器的负载压力;经过使用独立域名加快浏览器并发加载的速度。

  • 分布式数据和存储:大型网站须要处理以P为单位的海量数据,单台计算机没法提供如此大的存储空间,这些数据库须要分布式存储。

  • 分布式计算:目前网站广泛使用Hadoop和MapReduce分布式计算框架进行此类批处理计算,其特色是移动计算而不是移动数据,将计算程序分发到数据所在的位置以加速计算和分布式计算。

集群

对于用户访问集中的模块须要将独立部署的服务器集群化,即多台服务器部署相同的应用构成一个集群,经过负载均衡设备共同对外提供服务。
服务器集群可以为相同的服务提供更多的并发支持,所以当有更多的用户访问时,只须要向集群中加入新的机器便可;
另外能够实现当其中的某台服务器发生故障时,能够经过负载均衡的失效转移机制将请求转移至集群中其余的服务器上,所以能够提升系统的可用性。

缓存

缓存目的就是减轻服务器的计算,使数据直接返回给用户。
在如今的软件设计中,缓存已经无处不在。
具体实现有CDN、反向代理、本地缓存、分布式缓存等。

使用缓存有两个条件:访问数据热点不均衡,即某些频繁访问的数据须要放在缓存中;
数据在某个时间段内有效,不过很快过时,否在会由于数据过时而脏读,影响数据的正确性。

异步

使用异步,业务之间的消息传递不是同步调用,而是将一个业务操做分红多个阶段,每一个阶段之间经过共享数据的方法异步执行进行协做。
具体实现则在单一服务器内部可用经过多线程共享内存对了的方式处理;在分布式系统中可用经过分布式消息队列来实现异步。
异步架构的典型就是生产者消费者方式,二者不存在直接调用。

冗余

网站须要7×24小时连续运行,那么就得有相应的冗余机制,以防某台机器宕掉时没法访问,而冗余则能够经过部署至少两台服务器构成一个集群实现服务高可用。
数据库除了按期备份还须要实现冷热备份,甚至能够在全球范围内部署灾备数据中心。

水至清则无鱼嘛。

自动化

具体有自动化发布过程,自动化代码管理、自动化测试、自动化安全检测、自动化部署、自动化监控、自动化报警、自动化失效转移、自动化失效恢复等。

安全

网站在安全架构方面有许多模式:

  • 经过密码和手机校验码进行身份认证;
  • 登陆、交易须要对网络通讯进行加密;
  • 为了防止机器人程序滥用资源,须要使用验证码进行识别;
  • 对常见的XSS攻击、SQL注入须要编码转换;垃圾信息须要过滤等。

个人小网站从上线之初到如今也被攻击了好几回了,真的是无奈,就是一个为初学者演示的demo,你皮这一下以后颇有成就感吗?

结语

首发于个人我的博客.

之前嘛,看书基本都是看看热闹,如今的话,就会有更多本身的思考了,吃一堑长一智,虽然前人已经经过各类方式告知咱们一些事情,可是不少错依然会犯,只有痛了才知道。

end

我曾七次鄙视本身的灵魂:
第一次,当它本可进取时,却故做谦卑;
第二次,当它空虚时,用爱欲来填充;
第三次,在困难和容易之间,它选择了容易;
第四次,它犯了错,却借由别人也会犯错来宽慰本身;
第五次,它自由软弱,却把它认为是生命的坚韧;
第六次,当它鄙夷一张丑恶的嘴脸时,殊不知那正是本身面具中的一副;
第七次,它侧身于生活的污泥中虽不甘心,却又畏首畏尾。
 
 
 

JDK8 stream toMap() java.lang.IllegalStateException: Duplicate key异常解决(key重复)

 

测试又报bug啦

接到测试小伙伴的问题,说是一个接口不返回数据了,好吧,虽然不是我写的接口任务落到头上也得解决,本地调试了一下,好家伙,直接抛了个异常出来,这又是哪位大哥喝醉了写的代码...

Exception in thread "main" java.lang.IllegalStateException: Duplicate key at java.util.stream.Collectors.lambda$throwingMerger$0(Collectors.java:133) at java.util.HashMap.merge(HashMap.java:1254) at java.util.stream.Collectors.lambda$toMap$58(Collectors.java:1320) at java.util.stream.ReduceOps$3ReducingSink.accept(ReduceOps.java:169) at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1382) at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481) at java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:471) at java.util.stream.ReduceOps$ReduceOp.evaluateSequential(ReduceOps.java:708) at java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234) at java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:499) 

key重复异常解决

报错的那行代码以下:

Map<Long, Entity> entityMap= entityList.stream().collect(Collectors.toMap(Entity::getType, (entity) -> entity));

这行代码的目的就是将一个list对象转为map对象,以type为key,以entity对象为value。
可是与日常用的方法不一样,而是直接使用java8的stream方式,报错也很清楚,就是key重复,也就是说在使用toMap方法时,有重复的type值致使了这个报错,最终解决方式以下:

Map<Long, Entity> entityMap= entityList.stream().collect(Collectors.toMap(Entity::getType, Function.identity(),(entity1,entity2) -> entity1));

使用toMap()的重载方法,若是已经存在则再也不修改来避免重复key的问题。

顺便吐槽一下,这已是多久前的代码了,怎么今天才报出这个错,也是醉了。

我曾七次鄙视本身的灵魂: 第一次,当它本可进取时,却故做谦卑; 第二次,当它空虚时,用爱欲来填充; 第三次,在困难和容易之间,它选择了容易; 第四次,它犯了错,却借由别人也会犯错来宽慰本身; 第五次,它自由软弱,却把它认为是生命的坚韧; 第六次,当它鄙夷一张丑恶的嘴脸时,殊不知那正是本身面具中的一副; 第七次,它侧身于生活的污泥中虽不甘心,却又畏首畏尾。
相关文章
相关标签/搜索