TL;DR
《垃圾回收的算法与实现》一书的读书笔记。
《垃圾回收的算法与实现》
发表回复
分类目录归档：读书
泛读《Effective TCP/IP》
TL;DR
对《Effective TCP/IP》一书进行了浏览，记录了印象较为深刻的一些技巧。
有趣的是，《Unix网络编程》系列书籍的作者 W. Richard Stevens 对这本书的编写提供了一些帮助，而作者也认为阅读 Stevens 的书籍也是一个提高网络编程水平的44个技巧之一 :-)。
《Modern PHP》
PHP也是一门在不断变化的语言。
本书介绍了PHP 5.3之后出现的一些新特性，对PSR标准做了介绍，但是因为年代（2015年出版）的问题，PSR标准建议到官网进行阅读，本书最后还对配置、部署方面提出了一些建议。
《关键对话》
第1章 何谓关键对话
关键对话的定义
书中的关键对话指的是具有如下特征的对话：
- 对话对象为两人或者多人
- 对话双方观点有很大的分歧
- 对话存在很大的风险
- 对话双方情绪激烈
为什么要进行关键对话
电视剧：
逃避可耻但有用。
现实：
逃避可耻且没用。
第2章 掌握关键对话
成功的对话的定义
成功对话的标志在于相关信息的自由交流。
共享观点库
实际上是遵循一个原则：求同存异。目标是营造一个可以充分交流观点的环境。忌讳是不能玩冷战，不能过于明哲保身，或者使用各种暴力强迫他人接受自己的观点。
第3章 从“心”开始 如何确定目标
掌握关键对话的第一步，是认识自己，审视自己日常的沟通习惯。
关键对话中经常面对的问题
找错目标。
常见的问题是对人不对事。
思维惰性。
认定苦恼由他人造成，认定搞定“麻烦制造者”、“冲突对象”能解决问题。
寻求战胜对方。
从懵懂年纪就形成思维定式。
关键对话的重要原则
一切为了解决问题。
高风险对话中，必须明确对话的目的和动机，不能动摇。明确自己在这次对话乃至冲突中需要获得什么，不要转移注意力。
不做非黑即白的选择，问题不只是存在逃避和对抗，还能有对话这一个选择。避免这个情况的出现，需要对比说明这一方法，先明确期望实现的目的，再明确不期望的的目的，最终引导思维到寻求二者平衡的办法。
对话需要关注自身，对方，以及二者之间期望打成的目标，同时要明确实现这些目标的策略，
第4章 注意观察 如何判断对话氛围是否安全
沉默与暴力==失去安全感
沉默和暴力既是对话方失去安全感的标志。此时要做的是营造安全感，而不是对抗和反击。
沉默不仅仅是不发声，常见的形式还有掩饰（对问题轻描淡写，有所指，嘲讽）、逃避（持续对话但不谈论核心内容）和退缩（寻找借口不参与对话）。
暴力主要指言语暴力，控制（一言堂，胁迫对方按照个人思路解决问题，使用绝对字眼）、贴标签（人身攻击，故意简化问题并归类）和攻击是三种常见形式。
第5章 保证安全 如何让对方畅所欲言
营造安全感的原则
- 让对话存在共同目。让对话对象不认为自己只为自己的目的而开展对话。出现这类问题对话特征：当对话中存在自我防御，无端的指责和老调重弹。
- 相互尊重。出现这类问题对话特征：对话变得情绪化，咆哮，存在反击的话语。在对话过程中保持对不想尊重的对象的方法，可以把对方看做和自己是同类人，比较易于接受。
营造安全感的方法
及时暂停对话，必要的道歉，对比说明，创建共同对话目的。
对方出现沉默和言语暴力时，及时暂停对话。
必要的道歉用一点廉价的自尊心换来对话目的的打成，这是可以接受的。
对比说明既可以防范问题的发生，也可以挽救已出现问题的对话。
创建共同目的的四步法则是：冲突情况下积极寻求第三种方案，针对目的进行对话（即放下冲突的具体事件，直接沟通出现问题的原因），提出新的解决方案，就新的方案进行沟通。
第6章 控制想法 如何在愤怒、恐惧或受伤的情况下展开对话
主观臆断造成了情绪的泛滥。
解决的策略可以是在终止对话后，回顾自己的行为方式，质疑自身结论，寻找感受的事实依据，抛弃主观臆断，重新关注对话的目的。
简单来说，就是不为自身情绪找借口，而是关注对话目的。
第7章 陈述观点 如何循循善诱而非独断专行
讨论敏感问题
可以分为如下步骤：
- 分享事实经过
- 陈述个人想法
- 征询对方观点
- 做出试探表述（一定要软化修辞手段，尽量避免断言）
- 鼓励做出尝试
争论观点
适当的放弃强硬的态度，允许对方进行反馈，但是不对自身的观点进行让步。
第8章 了解动机 如何帮助对方走出沉默或暴力状态
倾听的手段
- 询问观点
- 确认感受（直接询问观点无效的情况下可以使用）
- 重新描述（一字不差的复述可以营造更大的安全感）
- 主动引导（提出个人的看法，建立共享观点库）
倾听之后的应对
赞同，补充，比较。
赞同是肯定共同之处，补充是赞同的观点进行补充，而比较则是通过综合陈述法（讲事实，说想法，鼓励对方响应）。
第9章 开始行动 如何把关键对话转变成行动和结果
对话之后需要进行决策，决策是把对话落地的必要步骤。
决策要让最少的人，最知情的人，和最受支持的人进行决策。
明确个人责任，里程碑，验收标准。
最后，一定要记录决策细节。
结论
关键的不是沟通，而是结果。
《微服务设计》
第1章 微服务
微服务就是一些协同工作的小而自治的服务。
大多数系统强调高内聚，低耦合，即通过抽象或者模块保证代码的内聚性。
一个基本的特征就是微服务是一个独立的实体。无论是在容器还是在进程中存在。
微服务通过API进行解耦合。
微服务的优点集中在：
- 技术可以异构
- 更大的弹性（可操作的粒度更大）
- 易于扩展（精细到功能级别）
- 简化部署（API接口不变，改动一个模块影响不大）
第2章 演化式架构师
架构师的一个重要职责是，确保团队有着共同的技术愿景，以帮助我们向客户交付他们想要的系统。
架构师要改变那种从一开始就要设计出完美产品的想法，而选择设计出一个合理的框架，在这个框架下可以慢慢的演化出正确的系统，一旦学到了跟过的的还是，可以加以使用。
架构师的职责之一是保证该系统适合开发人员在其之上工作。
架构师专注大方向，在优先的情况下参与到非常细节的具体实现上。
架构师关注服务边界之间的问题，而不应当过多关注边界内部的问题。
一个好服务至少要做到如下三个方面的优势：
+ 监控
+ 接口
+ 架构安全性
COBIT（Control Objectives for Information and Related Technology）给出的的治理的定义是：
治理通过评估干系人的需求、当前情况及下一步的可能性来确保企业目标的达成,
通过排优先级和做决策来设定方向。对于已经达成一致的方向和目标进行监督。
第3章 如何建模服务
服务要高内聚，低耦合，划分微服务的一个方式可以是找到各自功能的限界上下文（Bounded Context）。
第4章 集成
集成的几个原则：
- 技术的选择需要有收益
- 避免破坏性修改，对服务的修改不影响已有消费方
- 保证API的技术无关性，应该是需求驱动实现，而不是实现驱动需求
- 消费方易于使用，尽量不引入其他会引起耦合的使用方式（如client）
- 隐藏内部实现细节
共享数据库会带来的问题：
+ 所有使用者需要了解schema之间的细节
+ 消费方被绑定了技术
基于请求/响应模式的同步请求易于实现，而基于事件的异步请求模式则能应对长时操作以及降低耦合度。
编排（Orchestration）与协同（Choreography）的区别在于是否有有中心。编排会通过中心驱动流程。编排优点是状态和流程明确，问题在于中心负担过重，导致其他协作方过于单薄；协同的优点在于解耦合，问题在于需要额外的监控流程。异步是便于实现协同模式的通讯方式。
对于基于事件的异步协作方式，需要关注的地方在于事件的发布机制和接收机制。发布机制中需要注意的有：
+ 消息中间件要尽量简单，不要混杂业务逻辑
服务即状态机。
权衡DRY与微服务过程耦合的冲突，原则上是微服务内部DRY，跨服务可以适当违反DRY。
服务客户端的开发的要点是：
+ DRY
+ 处理与服务本身职责没有关系，但是又影响服务大规模运行部署的一些基础功能的部分（服务发现，故障模式，日志），只包含处理底层传输协议的代码
+ 由客户端决定升级时机
RPC与REST相比，客户端和服务端的部署无法分离。
第5章 分解单块系统
“接缝”的定义是，系统中可以抽取相对独立的一部分代码，这部分代码进行修改不会影响系统其他部分，是划分服务边界的依据。
分块的一些实例：
+ 外键约束通过业务逻辑实现
+ 对于共享的数据，通过单一服务单元进行操作
+ 共享的数据库表，拆分字段单元
+ 报表的导出，要么通过异步逻辑（提交请求异步导出），要么用一些软件（如列数据库），或者独立程序定期生成报表数据到其他数据库（类似InfluxDB中INTO的表现）
第6章 部署
每个微服务都建议有自己的CI流程。
如果可能，应该将每个服务都放到单独的主机或者容器之中，
部署的关键在于各个步骤的自动化。
第7章 测试
测试时主要关注对场景的测试，而非面面俱到。
想要频繁的发布版本，需要尽可能频繁的发布小范围的改变。
蓝/绿部署和金丝雀发布的区别在于，蓝绿是切全部流量，金丝雀发布是引导部分流量。并且Canary版本验证的内容会包括功能与非功能的，两个版本共存时间更长。Canary版本的好处在于可以对效果做更多的干预，通过实际运行效果评估开发的效果。
微服务中MTTR表现良好胜于MTBF。
第8章 监控
Web提供给监控系统的指标数据，最低要求就是提供响应时间和错误率。
为了便于监控系统追踪请求，可以使用全局ID的方式，贯穿整个请求的流程。
对于系统来说，对于数据的聚合，可以：
+ 聚合CPU一类的的主机层级的指标及应用程序程标（帮助找到程序性能瓶颈）
+ 要能回溯存储数据（Nagios的瓶颈，存储时间太短，可以加入第三方的存储组件）
第9章 安全
交给单点登录网关的应该是粗粒度的身份认证，而系统级别/业务级别的认证控制，应该在微服务内部实现。
权衡服务间的信任问题，可以根据操作的敏感程度，从低到高选择边界内隐式信任，验证调用方身份（验证access_token?），要求调用方提供原始主体凭证（如支付宝支付密码？）。
不要自己实现加密解密！不要发明自己的安全协议！要用行业的通用方式。
Datensparsamkeit：只存储完成业务运营或者满足当地法律所需的信息。没有存储，就没有丢失。
第10章 康威定律和系统设计
康威定律：任何组织在设计一套系统(广义概念上的系统)时,所交付的设计方案在结构上都与该组织的沟通结构保持一致。
团队结构影响开发成果（反康威定律也是有可能的）。
第11章 规模化微服务
设计微服务时的态度，就是假设一切都会失败。
权衡实现的复杂度，可以通过可接受的损失程度确定。
考虑跨功能服务发生故障时的场景，能明确定位和错误处理的实现。
级联的架构，必须要有保护机制，防止全站不可用。
主动制造故障驱动系统强壮性的增强（因人而异，无需极端追求）。
尽力追求操作幂等。
作业与执行逻辑分离，即通过worker实际执行任务，虽然可能中断或者执行缓慢，但是不至于造成任务丢失。
CAP中只能存在AP系统和CP系统。AP系统要实现最终一致，而CP系统通过拒绝服务保证C。CA系统因为牺牲了分区容忍性，根本不能跨网络运行，在分布式系统中，这完全与分布式不符合。
服务发现是规模化的一个重要组成部分。常规方案有：
+ DNS，通过名字引导流量到服务，缺点在于灵活性以及时效性不足
+ 动态服务注册，通过ZK等软件
第12章 总结
一切去中心化是微服务一个重要原则。
不了解系统承载的业务和特点之前，不要微服务化！不能自动化，不要微服务化！
> 变化是无法避免的，所以，拥抱它吧！
作者推荐书单：
其他关键词
- CQRS（Command-Query Responsibility Segregation）