极客时间：从0开始学架构

给大家带来的一篇关于架构相关的电子书资源，介绍了关于极客、架构方面的内容，本书是由电子工业出版社出版，格式为PDF，资源大小115 MB，李运华编写，目前豆瓣、亚马逊、当当、京东等电子书综合评分为：7.5。

内容介绍

这书循序渐进地论述了架构设计的相关内容，较为合适下列种类的读者：

•沒有架构设计工作经验，但对架构设计十分有兴趣爱好，期待学习架构设计技术性，提高技术性能力，变成“大型厂面霸”的读者；
•早已试着了一些架构设计，但挖了各种各样“坑”或踩了各种各样“坑”，期待了解“为何”的专业技术人员；
•具有一定的架构设计工作经验，想进一步专业化地提高架构设计能力，变成令人满意的“高級技术专家”“杰出技术专家”的读者。

架构设计是专业技术人员成才和升职全过程中务必把握的专业技能，但现阶段业内欠缺系统架构师学习和塑造层面系统化的专业知识和实践活动的具体指导，这书融合创作者很多年在架构设计层面的学习、思索、实践活动，明确提出了详细的一套架构设计方法论，包含什么叫构架、架构设计的目地、架构设计标准、架构设计步骤、架构设计方式和方法、互联网企业技术性演变等內容。这套架构设计方法论合适不一样制造行业，例如互联网技术、公司使用等；也合适不一样的技术领域，例如后端开发架构设计、前端开发架构设计、手机客户端架构设计、测试平台架构设计、运维平台架构设计等。

目录

• 第1部分  概念和基础
• 第１章  架构基础
• 1.1  “架构”到底指什么
• 1.1.1  系统与子系统
• 1.1.2  模块与组件
• 1.1.3  框架与架构
• 1.1.4  重新定义架构
• 1.2  架构设计的目的
• 1.2.1  架构设计的误区
• 1.2.2  以史为鉴
• 1.2.3  架构设计的真正目的
• 1.3  复杂度来源
• 1.3.1  高性能
• 1.3.2  高可用
• 1.3.3  可扩展性
• 1.3.4  低成本
• 1.3.5  安全
• 1.3.6  规模
• 1.4  本章小结
• 第2章  架构设计原则
• 2.1  合适原则
• 2.2  简单原则
• 2.3  演化原则
• 2.4  本章小结
• 第3章  架构设计流程
• 3.1  有的放矢—识别复杂度
• 3.2  按图索骥—设计备选方案
• 3.3  深思熟虑—评估和选择备选方案
• 3.3.1  业务背景
• 3.3.2  备选方案设计
• 3.3.3  备选方案360度环评
• 3.4  精雕细琢—详细方案设计
• 3.5  本章小结
• 第2部分  高性能架构模式
• 第4章  存储高性能
• 4.1  关系数据库
• 4.1.1  读写分离
• 4.1.2  分库分表
• 4.1.3  实现方法
• 4.2  NoSQL
• 4.2.1  K-V存储
• 4.2.2  文档数据库
• 4.2.3  列式数据库
• 4.2.4  全文搜索引擎
• 4.3  缓存
• 4.3.1  缓存穿透
• 4.3.2  缓存雪崩
• 4.3.3  缓存热点
• 4.4  本章小结
• 第5章  计算高性能
• 5.1  单服务器高性能
• 5.1.1  PPC
• 5.1.2  prefork
• 5.1.3  TPC
• 5.1.4  prethread
• 5.1.5  Reactor
• 5.1.6  Proactor
• 5.2  集群高性能
• 5.2.1  负载均衡分类
• 5.2.2  负载均衡架构
• 5.2.3  负载均衡的算法
• 5.3  本章小结
• 第3部分  高可用架构模式
• 第6章  CAP
• 6.1  CAP理论
• 6.1.1  一致性（Consistency）
• 6.1.2  可用性
• 6.1.3  分区容忍性（Partition Tolerance）
• 6.2  CAP应用
• 6.2.1  CP—Consistency/Partition Tolerance
• 6.2.2  AP—Availability/Partition Tolerance
• 6.3  CAP细节
• 6.4  ACID、BASE
• 6.4.1  ACID
• 6.4.2  BASE
• 6.5  本章小结
• 第7章  FMEA
• 7.1  FMEA介绍
• 7.2  FMEA方法
• 7.3  FMEA实战
• 7.4  本章小结
• 第8章  存储高可用
• 8.1  主备复制
• 8.1.1  基本实现
• 8.1.2  优缺点分析
• 8.2  主从复制
• 8.2.1  基本实现
• 8.2.2  优缺点分析
• 8.3  主备倒换与主从倒换
• 8.3.1  设计关键
• 8.3.2  常见架构
• 8.4  主主复制
• 8.5  数据集群
• 8.5.1  数据集中集群
• 8.5.2  数据分散集群
• 8.5.3  分布式事务算法
• 8.5.4  分布式一致性算法
• 8.6  数据分区
• 8.6.1  数据量
• 8.6.2  分区规则
• 8.6.3  复制规则
• 8.7  本章小结
• 第9章  计算高可用
• 9.1  主备
• 9.2  主从
• 9.3  对称集群
• 9.4  非对称集群
• 9.5  本章小结
• 第10章  业务高可用
• 10.1  异地多活
• 10.1.1  异地多活架构
• 10.1.2  异地多活设计技巧
• 10.1.3  异地多活设计步骤
• 10.2  接口级的故障应对方案
• 10.2.1  降级
• 10.2.2  熔断
• 10.2.3  限流
• 10.2.4  排队
• 10.3  本章小结
• 第4部分  可扩展架构模式
• 第11章  可扩展模式
• 11.1  可扩展概述
• 11.2  可扩展的基本思想
• 11.3  可扩展方式
• 11.4  本章小结
• 第12章  分层架构
• 12.1  分层架构类型
• 12.2  分层架构详解
• 12.3  本章小结
• 第13章  SOA架构
• 13.1  SOA历史
• 13.2  SOA详解
• 13.3  本章小结
• 第14章  微服务
• 14.1  微服务历史
• 14.2  微服务与SOA的关系
• 14.3  微服务的陷阱
• 14.4  微服务最佳实践
• 14.4.1  服务粒度
• 14.4.2  拆分方法
• 14.4.3  基础设施
• 14.5  本章小结
• 第15章  微内核架构
• 15.1  基本概念
• 15.2  设计关键点
• 15.3  OSGi架构简析
• 15.4  规则引擎架构简析
• 15.5  本章小结
• 第5部分  架构实战
• 第16章  消息队列设计实战
• 16.1  需求
• 16.2  设计流程
• 16.2.1  识别复杂度
• 16.2.2  设计备选方案
• 16.2.3  评估和选择备选方案
• 16.2.4  细化方案
• 16.3  本章小结
• 第17章  互联网架构演进
• 17.1  技术演进
• 17.1.1  技术演进的动力
• 17.1.2  淘宝
• 17.1.3  手机QQ
• 17.1.4  微信
• 17.2  技术演进的模式
• 17.3  互联网业务发展
• 17.3.1  业务复杂性
• 17.3.2  用户规模
• 17.3.3  量变到质变
• 17.4  本章小结
• 第18章  互联网架构模板
• 18.1  总体结构
• 18.2  存储层技术
• 18.2.1  SQL
• 18.2.2  NoSQL
• 18.2.3  小文件存储
• 18.2.4  大文件存储
• 18.3  开发层技术
• 18.3.1  开发框架
• 18.3.2  Web服务器
• 18.3.3  容器
• 18.4  服务层技术
• 18.4.1  配置中心
• 18.4.2  服务中心
• 18.4.3  消息队列
• 18.5  网络层技术
• 18.5.1  负载均衡
• 18.5.2  CDN
• 18.5.3  多机房
• 18.5.4  多中心
• 18.6  用户层技术
• 18.6.1  用户管理
• 18.6.2  消息推送
• 18.6.3  存储云与图片云
• 18.7  业务层技术
• 18.8  平台技术
• 18.8.1  运维平台
• 18.8.2  测试平台
• 18.8.3  数据平台
• 18.8.4  管理平台
• 18.9  本章小结
• 第19章  架构重构
• 19.1  有的放矢
• 19.2  合纵连横
• 19.2.1  合纵
• 19.2.2  连横
• 19.3  运筹帷幄
• 19.4  文武双全—项目管理 技术能力
• 19.5  本章小结
• 第20章  开源系统
• 20.1  选：如何选择一个开源项目
• 20.1.1  聚焦是否满足业务
• 20.1.2  聚焦是否成熟
• 20.1.3  聚焦运维能力
• 20.2  用：如何使用开源方案
• 20.2.1  深入研究，仔细测试
• 20.2.2  小心应用，灰度发布
• 20.2.3  做好应急，以防万一
• 20.3  改：如何基于开源项目做二次开发
• 20.3.1  保持纯洁，加以包装
• 20.3.2  发明你要的轮子
• 20.4  本章小结

学习笔记

美团DB数据同步到数据仓库的架构与实践

背景 在数据仓库建模中，未经任何加工处理的原始业务层数据，我们称之为ODS(Operational Data Store)数据。在互联网企业中，常见的ODS数据有业务日志数据（Log）和业务DB数据（DB）两类。对于业务DB数据来说，从MySQL等关系型数据库的业务数据进行采集，然后导入到Hive中，是进行数据仓库生产的重要环节。 如何准确、高效地把MySQL数据同步到Hive中？一般常用的解决方案是批量取数并Load：直连MySQL去Select表中的数据，然后存到本地文件作为中间存储，最后把文件Load到Hive表中。这种方案的优点是实现简单，但是随着业务的发展，缺点也逐渐暴露出来： 性能瓶颈：随着业务规模的增长，Select From MySQL - Save to……

mysql数据库应付大流量网站的的3种架构扩展方式介绍

数据库扩展大概分为以下几个步骤： 1、读写分离： 当数据库访问量还不是很大的时候，我们可以适当增加服务器，数据库主从复制的方式将读写分离； 2、垂直分区： 当写入操作一旦增加的时候，那么主从数据库将花更多的时间的放在数据同步上，这个时候服务器也是不堪重负的；那么就有了数据的垂直分区，数据的垂直分区思路是将写入操作比较频繁的数据表，如用户表_user,或者订单表_orders,那么我们就可以把这个两个表分离出来，放在不同的服务器，如果这两个表和其他表存在联表查询，那么就只能把原来的sql语句给拆分了，先查询一个表，在查询另一个，虽然说这个会消耗更过性能，但比起那……

浅析JavaWeb项目架构之Redis分布式日志队列

摘要： 架构、分布式、日志队列，标题自己都看着唬人，其实就是一个日志收集的功能，只不过中间加了一个Redis做消息队列罢了。 为什么需要消息队列？ 当系统中出现“生产“和“消费“的速度或稳定性等因素不一致的时候，就需要消息队列，作为抽象层，弥合双方的差异。 架构、分布式、日志队列，标题自己都看着唬人，其实就是一个日志收集的功能，只不过中间加了一个Redis做消息队列罢了。 为什么需要消息队列？ 当系统中出现“生产“和“消费“的速度或稳定性等因素不一致的时候，就需要消息队列，作为抽象层，弥合双方的差异。 比如我们系统中常见的邮件、短信发送，把这些不需要及……

大型JavaScript应用程序架构设计模式

PDF版的PPT下载地址：http://www.slideshare.net/jibyjohnc/jqquerysummit-largescale-javascript-application-architecture 注：在整理的过程中，发现作者有些思想是返来复去地说，所以删减了一部分，如果你的英文良好，请直接阅读英文的PPT。 以下是本文的主要章节： 1. 什么叫“JavaScript大型程序”？ 2. 顾当前的程序架构 3. 长远考虑 4. 头脑风暴 5. 建议的架构 5.1 设计模式 5.1.1 模块论 5.1.1.1 综述 5.1.1.2 Module模式 5.1.1.3 对象自面量 5.1.1.4 CommonJS模块 5.1.2 Facade模式 5.1.3 Mediator模式 5.2 应用到你的架构 5.2.1 Facade - 核心抽象 5.2.2 Mediator - 程序核心 5.2.3 紧密联合运作起来 6. 发布Pub/订阅Sub的延伸：自动注册事件 7. Q nbsp; custom widgets models……

详解mysql集群：一主多从架构实现

实验环境： 1、三台CentOS 7 服务器 2、mysql5.7.26（三台都通过yum安装） 服务器列表 7.100.222.111 master 47.103.211.5 slave1 47.103.98.221 slave2 如果还没安装mysql请看安装教程：mysql安装 一、概述： 架构图： 此种架构，一般初创企业比较常用，也便于后面步步的扩展 特点： 1、可以缓解读的压力。 2、成本低，布署快速、方便 3、读写分离 4、还能通过及时增加从库来减少读库压力 5、主库单点故障 6、数据一致性问题（同步延迟造成） 7、一但主机宕机就不可以进行写操作 二、搭建集群 1、修改配置文件 分别在三台服务器中使用如下命令修改配置文件 $ vim /etc/my.cnf 分别向三台服务器的/etc/my.cnf mysql配置文件添加如下内……

以上就是本次介绍的架构电子书的全部相关内容，希望我们整理的资源能够帮助到大家，感谢大家对码农之家的支持。

上一篇：Kubernetes权威指南：从Docker到Kubernetes实践全接触（纪念版）

下一篇：R语言实战：机器学习与数据分析