亿级流量网站架构核心技术：跟开涛学搭建高可用高并发系统 - (EPUB全文下载)

文件大小：0.26 mb。
文件格式：epub 格式。
书籍内容：

亿级流量网站架构核心技术：跟开涛学搭建高可用高并发系统
第1部分　概述
1　交易型系统设计的一些原则
第2部分　高可用
2　负载均衡与反向代理
3　隔离术
4　限流详解
5　降级特技
6　超时与重试机制
7　回滚机制
8　压测与预案
第3部分　高并发
9　应用级缓存
10　HTTP缓存
11　多级缓存
12　连接池线程池详解
13　异步并发实战
14　如何扩容
15　队列术
第4部分　案例
16　构建需求响应式亿级商品详情页
17　京东商品详情页服务闭环实践
18　使用OpenResty开发高性能Web应用
19　应用数据静态化架构高性能单页Web应用
20　使用OpenResty开发Web服务
21　使用OpenResty开发商品详情页
封底
第1部分　概述
· 高并发原则
· 高可用原则
· 业务设计原则
· 总结
1　交易型系统设计的一些原则
在我们的技术生涯中，总是不断针对新的需求去研发新的系统，而很多系统的设计都是可以触类旁通的。在设计系统时，要因场景、时间而异，一个系统也不是一下子就能设计得非常完美，在具有有限资源的情况下，一定是先解决当下最核心的问题，预测并发现未来可能出现的问题，一步步解决最痛点的问题。也就是说，系统设计是一个不断迭代的过程，在迭代中发现问题并修复问题，即满足需求的系统是不断迭代优化出来的，这是一个持续的过程，个人不相信完美架构银弹。不过，如果一开始就有好的基础系统设计，未来可以更容易达到一个比较满意的目标。一个好的设计要做到，解决现有需求和问题，把控实现和进度风险，预测和规划未来，不要过度设计，从迭代中演进和完善。
在设计系统时，应该多思考墨菲定律。
1.任何事都没有表面看起来那么简单。
2.所有的事都会比你预计的时间长。
3.可能出错的事总会出错。
4.如果你担心某种情况发生，那么它就更有可能发生。
在系统划分时，也要思考康威定律。
1.系统架构是公司组织架构的反映。
2.应该按照业务闭环进行系统拆分/组织架构划分，实现闭环/高内聚/低耦合，减少沟通成本。
3.如果沟通出现问题，那么就应该考虑进行系统和组织架构的调整。
4.在合适时机进行系统拆分，不要一开始就把系统/服务拆得非常细，虽然闭环，但是每个人维护的系统多，维护成本高。
应该多鼓励团队成员积极主动沟通并推动系统演进。另外，也要多思考二八定律，在系统设计初期将有限的资源用到刀刃上，以最小化可行产品方式迭代推进。
在持续开发系统的过程中，会有一些设计原则/经验可以用来遵循和指导我们。但设计原则应该在系统迭代过程中，根据现有问题或特征匹配使用，如果刚开始遇到的不是核心问题，那么不要复杂化系统设计，但先行规划和设计是有必要的，要对现有问题有方案，对未来架构有预案。
1.1　高并发原则
1.1.1　无状态
如果设计的应用是无状态的，那么应用比较容易进行水平扩展。实际生产环境可能是这样的：应用无状态，配置文件有状态。比如，不同的机房需要读取不同的数据源，此时，就需要通过配置文件或配置中心指定。
1.1.2　拆分
在系统设计初期，是做一个大而全的系统还是按功能模块拆分系统，这个需要根据环境进行权衡。比如，做私塾在线时，本身用户量/交易量不会特别大，开发就笔者一个人，资源有限，那就没必要对系统拆分（比如，拆分商品、订单等），做一个大而全的系统即可。而像设计京东秒杀系统，访问量是非常大的，而且投入的资源还是蛮充足的，在这种情况下，就可以考虑按功能拆分系统。
笔者遇到的拆分主要有如下几种情况。
系统维度：按照系统功能/业务拆分，比如商品系统、购物车、结算、订单系统等。
功能维度：对一个系统进行功能再拆分，比如，优惠券系统可以拆分为后台券创建系统、领券系统、用券系统等；
读写维度：根据读写比例特征进行拆分。比如，商品系统，交易的各个系统都会读取数据，读的量大于写，因此可以拆分成商品写服务、商品读服务；读服务可以考虑使用缓存提升性能；写的量太大时，需要考虑分库分表；有些聚合读取的场景，如商品详情页，可考虑数据异构拆分系统，将分散在多处的数据聚合到一处存储，以提升系统的性能和可靠性；
AOP维度：根据访问特征，按照AOP进行拆分，比如，商品详情页可以分为CDN、页面渲染系统；CDN就是一个AOP系统。
模块维度：比如，按照基础或者代码维护特征进行拆分，如基础模块分库分表、数据库连接池等；代码结构一般按照三层架构（Web、Service、DAO）进行划分。
1.1.3　服务化
首先，判断是不是只需要简单的单点远程服务调用，单机不行集群是不是就可以解决？在客户端注册多台机器并使用Nginx进行负载均衡是不是就可以解决？随着调用方越来越多，应该考虑使用服务自动注册和发现（如Dubbo使用ZooKeeper）。其次，还要考虑服务的分组/隔离，比如，有的系统访问量太大，导致把整个服务打挂，因此，需要为不同的调用方提供不同的服务分组，隔离访问。后期随着调用量的增加还要考虑服务的限流、黑白名单等。还有一些细节需要注意，如超时时间、重试机制、服务路由（能动态切换不同的分组）、故障补偿等，这些都会影响到服务的质量。
总结为：进程内服务→单机远程服务→集群手动注册服务→自动注册和发现服务→服务的分组/隔离/路由→服务治理如限流/黑白名单。
1.1.4　消息队列
消息队列是用来解耦一些不需要同步调用的服务或者订阅一些自己系统关心的变化。使用消息队列可以实现服务解耦（一对多消费）、异步处理、流量削峰/缓冲等。比如，电商系统中的交易订单数据，该数据有非常多的系统关心并订阅，比如，订单生产系统、定期送系统、订单风控系统等等。如果订阅者太多，那么订阅单个消息队列就会成为瓶颈，此时，需要考虑对消息队列进行多个镜像复制。
使用消息队列时，还要注意处理生产消息失败，以及消息重复接收时的场景。有些消息队列产品会提供生产重试功能，在达到指定重试次数还未生产成功时，会对外通知生产失败。这时，对于不能容忍生产失败的业务场景来说，一定要做好后续的数据处理工作，如持久化数据要同时增加日 ............

以上为书籍内容预览，如需阅读全文内容请下载EPUB源文件，祝您阅读愉快。