后端好书阅读与推荐（续八）

后端好书阅读与推荐系列文章：
后端好书阅读与推荐
后端好书阅读与推荐（续）
后端好书阅读与推荐（续二）
后端好书阅读与推荐（续三）
后端好书阅读与推荐（续四）
后端好书阅读与推荐（续五）
后端好书阅读与推荐（续六）
后端好书阅读与推荐（续七）
后端好书阅读与推荐（续八）

阿里巴巴Java开发手册

阿里巴巴Java开发手册 (豆瓣): https://book.douban.com/subje...

阿里在Java技术方面具备广阔而深刻的研究和应用，而本书正是阿里技术团队的集体智慧结晶和经验总结，很是值得借鉴和学习。

亮点：

• 现代软件行业的高速发展对开发者的综合素质要求愈来愈高，由于不只是编程知识点，其它维度的知识点也会影响到软件的最终交付质量。的确是这样，这一行不存在“一招鲜吃遍天”的说法，每一个人都要进行普遍而深刻的终身学习
• 现代软件架构的复杂性须要协同开发完成，如何高效地协同呢？无规矩不成方圆，无规范难以协同。适当的规范绝对不是扼杀创新性，而是管理软件复杂度的一种手段
• 为了达到代码自解释的目标，任何自定义编程元素在命名时，使用尽可能完整的单词组合来表达其意。不要嫌长，毕竟这是Java的一大特点(*￣︶￣)
• 任何类、方法、参数、变量，严控访问范围。过于宽泛的访问范围，不利于模块解耦。变量像本身的小孩，尽可能在本身的视线内，变量做用域太大，无限制的处处跑，那么你会担忧的。这一句说的很贴切
• 在高并发场景中，避免使用” 等于” 判断做为中断或退出的条件。若是并发控制没有处理好，容易产生等值判断被“击穿” 的状况（亦即瞬时状态跳变），使用大于或小于的区间判断条件来代替能够保证必定能终止
• 捕获异常与抛异常，必须是彻底匹配，或者捕获异常是抛异常的父类。若是预期对方抛的是绣球，实际接到的是铅球，就会产生意外状况。
• 好的单元测试必须遵照 AIR 原则：Automatic（自动的，不要人工的print而是自动的Assert）、Independent（独立的，不依赖于其余单元测试、也不依赖于其余模块，必要时能够Mock）、Repeatable（可重复执行，支持持续集成）
• 对用户相关的数据要作校验（防止攻击）、鉴权（防止越权操做）、脱敏（防止信息泄露）、转义展现（避免代码逻辑泄露，或者让用户懵逼），还要作防刷（避免资损或骚扰用户）、违禁词过滤等风控策略
• MySQL中 varchar 是可变长字符串，不预先分配存储空间，长度不要超过 5000，若是长度大于此值，定义字段类型为 text，独立一张表，用主键对应，避免影响其它字段索引效率（由于MySQL是按行存储的）
• 分层设计中，Dao层异常不要打印，而是直接抛出，由于Service层必定会借助日志并记录；web层毫不应抛出异常，由于已处于顶层，应本身记录，并选择合适页面渲染给用户；对于领域对象，DO与数据表一致,DTO是service向外传输对象,BO是Service层封装的业务逻辑对象,AO是Web与Service之间的复用对象模型,VO是显示层对象,Querry是上层给下层的查询对象

书比较薄，涉及面也较广，能够把本书当作一个目录，咱们本身按需去发散，针对每一个方面进行更深刻的学习。
此外本书还有进阶版，能够看作是对本书的一个扩充。

Clean Architecture

Clean Architecture (豆瓣): https://book.douban.com/subje...

本书是代码整洁之道做者 Robert C·Martin 的Clean系列的最新大做，译为架构整洁之道，是做者多年软件架构经验的合集，值得细细品味。

亮点：

• 软件架构的终极目标是用最小的人力成原本构建知足和维护该系统的需求。若是你以为好的架构太费钱，大可看看先用随意的架构而后再慢慢改的成本，事实上国内好多公司也是这样作的，都是快速扩张追求速度，后面再慢慢还技术债。从软件开发的角度看，一开始偷懒妄想后期重构是不大可能的（由于市场的压力永远不会消退，你永远都在完成新功能，重构旧代码的机会不会再有了，系统愈来愈乱），因此精心设计的架构的确对后来的工做有好处，可是我以为对于须要快速抢占市场的应用，先跑起来才是王道，这是已经超出了软件开发的范畴的理念。
• 软件的价值来自于两个维度：行为（业务逻辑，是直接产生利润的价值，也是大多数人惟一关注的价值）和架构（软件的灵活性，具体下来能够理解为可扩展性、复杂性管理等，这部分价值常被人忽略，但确是软件能够持续低成本地产生行为价值的基础，也是软件之因此“软的缘由”）。若是用艾森豪威尔矩阵来衡量，行为价值是紧急的，但并不老是特别重要，架构价值是重要的，但并不老是特别紧急。咱们须要很好的平衡这两个价值
• 结构化编程限制了goto语句，赋予了咱们创造可证伪程序单元的能力，相应的，在架构领域，功能性降解拆分是最佳实践之一；C支持完美的封装，部分支持继承（结构体超集），支持多态（函数指针模拟，getchar、putchar等函数），因此这三大特性并不能表明OOP，OOP的真正精髓在于对于程序间接控制权的转移，亦即安全的多态（好比Java将函数指针封装到jvm中，程序员不可直接用指针了），这种多态能方便地实现依赖反转（implemention源码依赖于interface，控制流和源码依赖相反），让底层组件插件化，独立于高层组件进行开发和部署（边界划分的艺术）；函数式编程中变量（叫参数更好）不可变，借鉴到架构中就是隔离不可变与可变的部分（咱们目前作不到彻底不可变性，要么速度太慢，要么空间过小，若是有足够的空间和速度，就能够实现只需CR而不是CRUD的程序）
• 软件构建的底层目标（也就是具体的代码逻辑，类比砖头）应遵循“整洁之道”；中层目标（也就是组件，类比房间）是软件可容忍改动、更易理解、组件可复用，应遵循SOLID原则（是设计类和模块适用的原则，在架构领域也适用）；高层目标（也就是软件系统。类比建筑）要遵循复用和发布等同（为复用而组合）、共同闭包（为维护性而组合）、共同复用（为避免没必要要的发布而切分）三个原则，这三个原则互相牵制，架构师要在这三者中找到平衡；组件之间要避免循环依赖，打破循环依赖的方式有DIP、建立新组件两种方式，依赖要指向更稳定的方向
• 软件架构师首先是程序员，也许不是代码量最多的，可是应该亲自承接编程任务，否则体会不到不良设计带来的麻烦，逐渐就会迷失正确的设计方向；软件架构的最高优先级是系统正常工做，同时也要保留尽量多的选项（这是让系统好理解、可扩展、易修改，为其未来正常工做打下基础），架构是要考虑软件系统的全周期，而非仅是当前；软件架构的目标是让系统的策略和细节分离，以容许具体决策过程当中推迟与细节相关的内容，留下更多的选项
• 咱们常说“Don't repeat yourself”，颇有可能就陷入了见到重复就消灭的应激模式中，事实上，要区分真重复和假重复，若是两段代码走的是不一样的演进路径，那么即便他们如今看起来比较像也要即时分开，否则后期的改动就会难如下手

我发现老外写书大体有两种风格，一种是大部头，经书似的。这种书看着人头疼，可是每每能把一个领域说的很是清楚和考究，属于科研派的，好比TCP/IP详解 卷1：协议这种；另外一种是散文似的，每一部分都短小精悍，看着也不累，好比Head First 设计模式。这本书显然是后者，感受学了很多，也不以为累，究其缘由我想是由于本书通篇就反复讲了一个概念：隔离变化（重要的事情说三遍？），因此看完仍是感受稍微有点水。

可伸缩架构

可伸缩架构：面向增加应用的高可用 (豆瓣): https://book.douban.com/subje...

高可用是咱们作系统的人不变的追求，本书就是该领域的一部佳做，从可用性谈起，介绍了监控并提升可用性的方法，而后重点讲了风险管理和伸缩性，最后讲了最近几年流行的微服务和逐渐成为主流趋势的上云。看完以后就能对高可用这个概念有一个全面系统的了解。

亮点：

• 程序员一开始接触的是一个肯定性的世界，什么样的输入就有什么样的输出，可是在面对分布式系统时首先要认可的就是不肯定性，不能再把系统看作单体应用那样稳定，要充分考虑不肯定状态（机器自己、代码质量、网络等因素所致），并把整个系统的不肯定性因素梳理出来，做为风险进行管理，制定相应的措施，并持续地进行测试和评估，避免问题发生时手足无措
• 提升可用性的5个要点：时刻考虑应对故障（everything can fail at anytime，因此要为故障作出计划）；时刻考虑应对伸缩（具有快速扩展数据库、应用等的能力）；缓和风险（风险不能彻底消除，可是应该作出缓和风险亦即下降问题带来的影响的努力）；监控可用性（眼睛，问题定位）；以可预期及明确的方式来处理可用性问题（对监控出的问题进行标准化流程处理，下降不可用时间）
• 计划和平常维护致使的不可用时间也应计算在可用性百分比之中，由于用户只在意可用与否，而无论你是意外故障仍是计划维修
• 可用性降低时有几点能够作：首先要跟踪并测量可用性（包括关键事件如变动和可用性之间的关系）；手动流程自动化（人肉操做不靠谱，自动化操做则有预期、可审查、可重复、易版本控制和回滚）；关注一致性、可重复性、标准的配置管理流程
• 风险管理就是在消除风险的成本与风险发生的成本之间保持平衡，其第一步就是列出全部已知风险，包括可能性和危害性并依此分级（最严重的风险天然就是可能性大、危害性大的），制定风险缓和措施（下降可能性和危害性，危险性更要首先关注）来控制风险并按期检查和持续维护（比赛日，也就是容灾演练）。当风险仍然不可避免的发生后采用恢复计划（风险发生后采起的行动，也属于风险缓和措施，如容灾计划）下降问题的危害性
• 如何从根本上缓和风险呢？那就是从一开始就考虑构建低风险系统，要素有：冗余（合适的冗余能够下降总体故障几率，可是过分冗余带来了复杂性，反而增长了风险）、幂等接口（经过简单重试避免失败）、独立性（看似冗余的服务若是运行中同一个物理机或者机架上那就不独立了）、简单（微服务下降了单体复杂性，可是服务数量增多也带来了构建大规模系统的总体复杂性，因此构建微服务要在单个服务和总体应用之间的复杂性作权衡，这个权衡取决于你的系统、组织和公司文化）、自修复（人工修复会显著下降可用性，好比半夜你还得先起床，因此要自修复，好比负载均衡自动剔除坏server、热备数据库自动上线等）、自动化流程（人老是会犯错）
• 微服务主要解决的是单体程序臃肿难理解、没法多组人员并行开发、难以测试、发布缓慢等问题，且能够给更重要的业务单独增长更多资源，固然这个进步的前提是服务之间边界明确且独立（代码库、数据、API、Owner的权利和责任），不然既不能解决这些问题，反而因为组件数量增多而增长了系统的复杂性。服务边界划分的原则有：业务需求、团队全部权、自然隔离的数据、对外服务的能力
• AWS的可用区针对不一样用户来讲是不一样的，主要是为了负载均衡，避免用户集中选择字母表中靠前字母的可用区，致使负载不均，同一个数据中心对甲是a可能对乙就是b，这个设计仍是挺巧妙的

文中说可靠性很容易经过测试解决，因此主要讲了可用性，可是分布式数据一致性、持久化等也应属于可靠性，可是很难测试，因此书里的可靠性定义仍是狭隘了一点，仅指传统软件测试方面的。并且我以为广义上的可靠性应该是包含正确性和可用性两方面的，而广义上的可用性又包含能用和性能两方面（好比你的一个简单的服务虽然能用，可是RT是5分钟也可认为该服务是不可用的）。
另外后面关于云计算方面的内容稍有注水和广告之嫌，毕竟按固定量和使用量的方式分配资源这种话题太过浅显（虽然也属于伸缩性的范畴）。

软件架构师的12项修炼

软件架构师的12项修炼 (豆瓣): https://book.douban.com/subje...

架构师的技术能力属于硬技能，关系技能、我的技能和商务技能等属于软技能。在商业化的社会，硬技能的确很是重要，是咱们生存的基础，可是软技能也一样重要，是咱们扩大影响力和业务面的基础，能帮咱们超脱技术自己，为公司创造利润，为社会创造价值。这本书就着重帮咱们培养这些软技能，而且基本按照原则、策略等要点来组织，很是有条理。

亮点：

• 对于更高职位的人而言，深谙技术细节当然有用，但能力已经开始向与别人成功交互方向倾斜，为了将事情办成而倾销其观点，一个项目要成功，支付帐单的人要得到最大回报其实并不必定须要完美的技术解决方案，因此赶上争执首先问本身：纠正重要吗？不纠正公司会付出很大成本吗？很大可能答案是不，此时最好就是保持平静而非面红耳赤，记住人不是软件（有问题就必定要立马解决），人有情绪，因此要时刻保持文雅
• 就像好的web服务同样，你应采用“无状态”的方式——只对当前输入作出响应（而不是好久以前别人对你冒犯），毕竟你的脑子是能处理几件事，不要将你的精力浪费在过期、无用的信息上，记住你学会的知识，放下不快的事情，你会成为一个真正进步、快乐的人
• 架构师一般不能直接管理别人，这样指示别人完成特定行动的能力就受到限制了，因此真正有效的手段就是你的影响力，一方面体如今你的专业知识上，另外一方面就是沟通技能
• 出于本能，当别人说出对咱们不是正面意义的话的时候咱们每每会找借口、转移话题或者责怪别人，但事实上别人不必定出于恶意，先想一想本身能从别人的话中获得改进吗？若是是，则是你成长的机会，因此要避免这种本能
• 咱们经常会说“我早就告诉你会这样”，是下意识的想展现本身的优越感或者甩锅，可是这样对团队合做与项目进度毫无用处，因此要想成为一名好的team worker，咱们要扔掉许多下意识的东西，而且尝试去了解肢体语言和心理学能够帮你更好的进行协商
• 管理是将事情作对，而领导力是作对的事。应该经过影响而不是要求别人来作一件事才是真正的领导力。领导力创建于信任之上，是为了创建一种共识，取决于创建战略伙伴关系和身体力行的能力。
• 透明化能为本身和他人带来清晰性，让公司充分评估风险。包括三大类：自我透明，向别人充分展现本身，不隐藏，让别人可信赖并对你有合理的期待；项目透明，展现项目的优缺点、风险、成本和假设条件，让别人也能够充分参与决策；关系透明，给别人信任，倾听，让别人对你也透明
• 激情是推进你事业进步的内在动力
• 商务就是为了赚钱，了解一些商务知识能够大大促进你了解伙伴（市场、销售）、领导和客户的能力，能帮你作出真正有商业价值的产品。
• 创新不会凭空而来，须要多阅读（书记、博客等），这样你才有知识储备，在你面临一个挑战性问题时，你才有原材料进行创新；平时有了点子均可以记录下来（好记性的确不如烂笔头，并且现在你们都很忙，不少想法不记录就溜走了），这就是未来灵感的种子

这本书还有个好处就是全书都在培养咱们问本身问题的习惯，赶上一件事时先全方位多角度地问本身若干问题，而后再下手，这样才不会片面，不会走入“锤子与钉子”的桎梏，才能有更宽阔的眼界，走向创新的大门。
另外说一点和书不要紧的话，咱们工做中本身是锤子，不能看见啥都是钉子，这样容易走入死胡同。可是咱们本身是锤子，看见啥都要想想是否是钉子，这样才有可能发挥本身工做的最大价值。
最后，我以为本书不仅是架构师须要，而是各行各业的各种人都须要。

和秋叶一块儿学PPT

和秋叶一块儿学PPT (豆瓣): https://book.douban.com/subje...

若是说代码能力、架构能力等技能属于咱们的硬实力，那么表达能力、沟通能力就是咱们的软实力，只有软硬兼修才能立于不败之地。在现在的学习和工做中，少不了汇报、组会等，制做一个好的PPT能帮咱们更好地表达、展示和沟通。经过本书能够学到PPT的制做技术，并且书自己就能够看作一个素材库，针对不一样行业、场合，帮助你选择不一样的风格和素材，适合长留案边，以备不时之需。

亮点：

• 感受写书和写PPT有共性，做者一开始就把本身的书和其余书做对比，强调突出了本身的优点（好比同名微博+微信+书籍，打造学习闭环），一会儿就把我震住了，可见PPT作得好不只能会说，还能会写书，好处多多
• 从结果导向来讲，仍是要关注业务。office2003出来后，一众发烧友作了一大堆复杂动画模拟翻书切换效果，结果office2010直接一键实现，因此对于好多工具（好比开发语言、中间件）不必耗费时间彻底搞清楚它全部花里胡哨看起来高大上的特性，而是要关注业务的实现，在必要的时候再去了解特性（由于所谓特性其实很容易过期）
• serif（有衬线字体），在字的笔画开始、结束的地方有额外的装饰，且笔画的粗细有所不一样；反之，sans serif 没有额外的装饰，且笔画的粗细差很少。投影状态下受设备影响，大字部分适合serif（透气、美观） ，小字部分适合sans serif（简洁、识别度高、有冲击力）；此外，不一样字体的使用要注意法律风险
• 打造一个高大上的PPT其实也是有章可循的，通常四步走起：统一字体、突出标题、巧取颜色（经过沿用logo或企业VI用色对PPT进行简单配色）和快速搜图（用关键词搜图法对PPT进行配图）
• ......

这本书连真小白均可以看，因此老手们要跳着看啊，否则浪费不少时间（好比教你怎么下百度云，￣□￣｜｜）。

Kubernetes in Action

Kubernetes in Action中文版 (豆瓣): https://book.douban.com/subje...

xx in action 系列的书一直不错，既有原理性的解读，又有实战性的上手指导，阅读价值很是高。而k8s做为云原生的表明技术，很是值得学习。

亮点：

• Kubermetes 抽象了数据中心的硬件基础设施，使得对外暴露的只是一个巨大的资源地，能够被看成集群的一个操做系统 看待，它让咱们在部署和运行组件时，不用关注底层的服务器，使开发者能够自主部署应用，彻底脱离运维团队的帮助，同时能让运维团队监控整个系统，而且在硬件故障时从新调度应用，系统管理员的工做重心，从监管应用转移到了监管 Kubermetes，以及剩余的系统资源，由于 Kubermetes 会帮助监管全部的应用
• 做者不喜欢先解释事物是如何工做的，而后再解释它的功能并教人们如何使用它 。 就像学习开车，你不想知道引擎盖下是什么，你首先想要学习怎样从 A 点开到 B 点 。只有在你学会了如何作到这一点后，你才会对汽车如何使这成为可能产生兴趣。毕竟，知道引擎盖下面是什么，可能在有一天它抛锚后你被困在路边时，会帮助你让车再次移动
• 一个 pod 是一组紧密相关的容器，它们老是一块儿运行在同一个工做节点上，以及同一个 Linux 命名空间中。为何发明了pod的概念呢？ 首先，容器被设计为每一个容器只运行一个进程（除非进程自己产生子进程），若是在单个容器中运行多个不相关的进程，那么保持全部进程运行、管理它们的日志等将会是咱们的责任，因此不能将多个进程汇集在一个单独的容器中，咱们须要另外一种更高级的结构来将容器绑定在一块儿，并将它们做为一个单元进行管理，这就是 pod 背后的根本原理
• 注解也是键值对，因此们本质上与标签很是类似，但注解并非为了保存标识信息而存在的，通常用来保存更多的信息，而标签更像是索引。此外，向Kubemetes引入新特性时，一般也会使用注解，通常来讲，新功能的alpha和beta版本不会向API对象引入任何新字段而是用注解，当API更改变得清晰并获得全部相关人员的承认，就会引入新的字段并废弃相关注解。
• 尽管工做节点上的组件都须要运行在同一个节点上，控制平面的组件能够被简单地分割在多台服务器上。为了保证高可用性，控制平面的每一个组件能够有多个实例。etcd和API服务器的多个实例能够同时并行工做，可是调度器和控制器管理器在给定时间内只能有一个实例起做用，其余实例处于待命模式
• 控制器执行一个“调和”循环，将实际状态调整为指望状态（在资源spec部分定义），而后将新的实际状态写入资源的 status 部分。控制器监听API Server来订阅变动，但使用监听机制并不保证不漏掉事件，因此仍然要按期执行重列举操做来确保不会丢掉什么
• ......

Kubernetes网络权威指南

Kubernetes网络权威指南：基础、原理与实践 (豆瓣): https://book.douban.com/subje...

本书是要不要推荐我其实犹豫了一下，由于本书有许多代码，有充数之嫌，并且在阐述上有许多不清晰的地方。可是我仍是推荐给你们，由于本书勾勒了一个基本上完整的k8s网络大图，值得通盘了解。

亮点：

• 结合CNM，Libnetwork要达成的效果是，用户能够建立多个网络，也能够建立多个容器，最后选择让容器加入某个网络，从而使容器和网络分离，让开发者专一于本身感兴趣的地方
• 要支持大规模的容器集群，网络才是最基础的一环，其中的挑战是“以隔离的方式部署容器，在提供隔离本身容器内数据所需功能的同时，保持有效的链接”，隔离和链接是两个矛盾可是又缺一不可的关键词
• Overlay是指在传统底层网络上构建一个虚拟网络，底层网络不需作任何适配，虚拟网络在底层网络上进行封包拆包完成通讯，L2 overlay是一个大二层的概念，大是指这个网络能够跨越数据中心，二层是指通讯双方在一个逻辑网段内，支持容器迁移而不用改变Ip的特性，L3 overlay相似，可是在节点上增长网关（不一样节点网段能够不一样），节点内通讯走L2,节点间走L3；Underlay是指底层网络，传统组网就是underlay类型，L2 underlay就是2层互通的网络，L3 underlay就是L3互通的网络
• Docker在容器的普及和迅速推广起到了很是重要的做用，可是它也正在集成网络、编排等功能，势必会被k8s弱化其做用，而拥抱更轻量的容器技术好比containerd、cri-o等
• k8s网络策略和一些安全组在某些功能上有重叠，可是区别也较为明显，安全组通常记录在上层网关，网络策略则实施在每一个节点上，节点上的agent须要watch pod、namespace、policy等资源
• Linux内核在作SNAT时，因为端口分配和将链接插入contrack表存在时延，可能致使端口冲突而丢包（尤为是高并发模式下），因此不推荐在生产环境使用nodePort模式
• 受制于k8s的基于客户端的负载均衡架构（由每一个节点的kube-proxy决定real server），即便用了支持多种负载均衡算法的ipvs也很难支持，好比least-connection算法，每一个kube-proxy只能知道本身连接数最小的rs，而不能知道全局最小的rs
• Flannel 经过监视etcd获取可用ip范围，在启动容器时指定ip范围，从而使得不一样节点成为一个子网，容器ip不重复；经过overlay（用户态udp或内核态的vxlan）或者host-gateway（直接刷节点路由表，因为不能刷路由器因此须要节点2层可达）的方式实现容器间通讯。Calico 也是经过相似的刷节点（虚拟路由器）路由表来实现容器通讯，可是因为采用了BGP协议，其模拟的路由表信息能够被传递到其它路由设备中，直接实现了3层网络通讯
• BPF 能够理解为一个高性能沙箱，使得内核变成可编程，内核有其加持后，linux的安全则不局限于传统的ip+port的包过滤模式，内核能够理解什么是微服务、安全性如何等问题。Cilium就把BPF带入了K8S

大型系统应用架构实战

大型系统应用架构实战：部署、容灾、性能优化 (豆瓣): https://book.douban.com/subje...

本书做为阿里全球化的经验沉淀之做，不只介绍了宏观的架构策略，还探讨了具体的算法实现，很是值得急速扩张的互联网公司借鉴。
此外，本书展示出来的知识面也告诉咱们，要想做一个优秀的架构师，既要了解业务，也要了解技术，这样才能作出最适合业务的技术方案

亮点：

• 互联网的本质是提升信息传递的效率，它极大地促进了全球化，而全球化对技术有以下几个要求：性能、可用性、互联互通、数据一致性、隐私保护、本地化对接、可伸缩性
• 区域化部署技术的本质是多层路由，每一层都要基于用户来调用路由服务，肯定该用户所属的机房。而多层路由的最佳方式是接入层RPC调用路由服务后缓存起来（有必定的失效期）并透传给下面的服务层、消息层和数据层。有人可能会问了，都在接入层判断了，为啥后面每一层都要再判断一次？由于有可能路由服务变动了，还有可能一份数据被多个用户共享，因此每一层都要作路由决策
• 区域化容灾技术，在进行灾备切换时并不须要更新整个机房的用户路由表，也不会由于彻底依赖DNS切换而必须等待DNS失效，由于区域化部署已经提早在路由服务中准备好了灾备机房，因此在统一接入层便可完成灾备切换，即便统一接入挂了，也只是会影响部分用户而不会带来危害
• ......

后记

有时候会以为“知道了许多道理，却依然过很差这一辈子”，看了许多书，却以为本身依然没有进步。我以为主要有两点，一是看书要带着思考去看，不要用眼睛过一遍就完事了，要对书中的内容多想一想：书里说的对不对？若是是对的我有没有作到？书对个人学习和工做有实际价值吗？等等，多问几个问题书里的内容就能天然而然转化为本身的知识，日常和别人交流就能用上了。二是要及时地把书中的知识运用起来，并有意识的对本身进行相应的训练，好比对于很内向的人，看了《架构师修炼这本书》后就能够好好实践一下透明化这一章节，多展现本身，让别人了解并信任你，这就是你的进步。

查看原文，来自MageekChiu。