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

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

前言

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

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

一般来说软件架构需要关注性能、可用性、伸缩性、扩展性和安全性这5个架构要素。

性能

性能是网站架构设计的一个重要方面，任何软件架构设计方案都必须考虑可能带来的性能问题，也正因为性能问题几乎无处不在，所以优化网站性能的手段也非常多。

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

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

可用性

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

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

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

伸缩性

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

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

扩展性

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

衡量网站架构扩展性好坏的主要标准就是在网站增加新的业务产品时，是否可以实现对现有产品透明无影响，不同产品之间是否很少耦合等。

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

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

安全性

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

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

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

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

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

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

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

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

如图：

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

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

前言

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

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

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

分层

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

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

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

分隔

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

分布式

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

分布式应用和服务：将分层和分隔后的应用和服务模块分布式部署，可以改善网站性能和并发性、加快开发和发布速度、减少数据库连接资源消耗。
分布式静态资源：网站的静态资源如JS、CSS、Logo图片等资源对立分布式部署，并采用独立的域名，即人们常说的动静分离。静态资源分布式部署可以减轻应用服务器的负载压力；通过使用独立域名加快浏览器并发加载的速度。
分布式数据和存储：大型网站需要处理以P为单位的海量数据，单台计算机无法提供如此大的存储空间，这些数据库需要分布式存储。
分布式计算：目前网站普遍使用Hadoop和MapReduce分布式计算框架进行此类批处理计算，其特点是移动计算而不是移动数据，将计算程序分发到数据所在的位置以加速计算和分布式计算。

集群

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

缓存

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

使用缓存有两个条件：访问数据热点不均衡，即某些频繁访问的数据需要放在缓存中；
数据在某个时间段内有效，不过很快过期，否在会因为数据过期而脏读，影响数据的正确性。

异步

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

冗余

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

水至清则无鱼嘛。

自动化

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

安全

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

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

我的小网站从上线之初到现在也被攻击了好几次了，真的是无奈，就是一个为初学者演示的demo，你皮这一下之后很有成就感吗？

结语

首发于我的个人博客.

以前嘛，看书基本都是看看热闹，现在的话，就会有更多自己的思考了，吃一堑长一智，虽然前人已经通过各种方式告知我们一些事情，但是很多错依然会犯，只有痛了才知道。

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的问题。

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