标签：douban www 左耳 http 听风要记 https com subject

阅读要记-《左耳听风》

1

Equifax 信息泄露始末

《代码大全》虽然这本书有点过时了，而且厚到可以垫显示器，但是这绝对是一本经典的书。
《程序员修练之道》这本书也是相当经典，我觉得就是你的指路明灯。
《计算机的构造和解释》经典中的经典，必读。
《算法导论》美国的本科生教材，这本书应该也是中国计算机学生的教材。
《设计模式》这本书是面向对象设计的经典书籍。
《重构》代码坏味道和相应代码的最佳实践。
《人月神话》这本书可能也有点过时了，但还是经典书。
《代码整洁之道》细节之处的效率，完美和简单。
《Effective C++》/
《More Effective C++》 C++ 中两本经典得不能再经典的书。也许你觉得 C++ 复杂，但这两本书中带来对代码稳定性的探索方式让人受益，因为这种思维方式同样可以用在其它地方。以至于各种模仿者，比如
《Effective Java》也是一本经典书。
《Unix 编程艺术》
《Unix 高级环境编程》也是相关的经典。

BOSS VS LEADER

BOSS	LEADER
驱动员工	指导员工
制造畏惧	制造热情
面对错误,喜欢使用人事惩罚手段	面对错误,喜欢寻找解决问题的技术或管理办法
只知道怎么做	展示怎么做
用人	发展人
从团队收割成绩	给予团队成绩
喜欢命令和控制	喜欢沟通和协作
喜欢说,“给我上”	喜欢说,“跟我上”

https://www.joelonsoftware.com/2005/05/11/making-wrong-code-look-wrong/

错误处理的最佳实践总结如下：

统一分类的错误字典：在错误码或异常捕捉时，需要将错误进行分类，并统一定义相关的错误。建议在一个地方定义错误，比如使用HTTP的4XX表示客户端问题，5XX表示服务端问题。创建一个错误字典可以提高代码的可维护性和重用性。
同类错误的定义可扩展：通过面向对象的继承或接口多态的方式，可以定义同类错误，并方便地扩展已有的代码。这种方式能够更好地处理错误的分类和处理逻辑。
定义错误的严重程度：根据错误的严重程度，如Fatal（重大错误）、Error（资源或需求问题）、Warning（需要注意但不一定是错误）、Info（信息）、Debug（调试信息），来标识错误的级别。
使用错误码而非错误信息进行错误日志输出：在打印错误日志时，最好使用统一的格式，并使用错误码而非错误信息。错误码可以是一个能从错误字典中找到的关键字，有利于自动化监控和日志分析。
忽略错误需记录日志：在忽略错误时，最好记录相应的日志，否则会给维护带来困扰。对于同一个地方不断报错的情况，不建议每次都打印日志，而是记录错误以及出现的次数。
不要将错误处理逻辑用于业务逻辑：避免使用异常捕捉等错误处理方式来处理业务逻辑，应该使用条件判断。异常捕捉用于处理意外情况，而错误码用于处理可能发生的事情。
对于同类错误处理使用一致的模式：针对同类的错误处理，应该使用相同的模式，比如对于null对象的错误，要么都返回null并加上条件检查，要么都抛出NullPointerException。避免混用，以保持代码规范。
尽可能在错误发生的地方处理错误：在错误发生的地方处理错误可以简化调用者的逻辑。将错误尽早处理可以减少错误的传递和副作用。
向上返回原始错误：如果必须将错误返回给更高层进行处理，应该返回原始的错误而不是重新创建一个错误。这样可以保持错误的准确性和完整性。
错误处理时总是要进行清理：在处理错误时，需要进行清理已分配的资源，以确保程序的稳定性和资源管理的正确性。

这些是错误处理的最佳实践，根据具体情况和需求而定。

魔数 0x5f3759df

《雷神之锤 III 竞技场》源代码中的一个函数（已经剥离了 C 语言预处理器的指令）

float Q_rsqrt( float number )
{
    long i;
    float x2, y;
    const float threehalfs = 1.5F;

    x2 = number * 0.5F;
    y  = number;
    i  = * ( long * ) &y; // evil floating point bit level hacking
    i  = 0x5f3759df - ( i >> 1 );  // what the fuck? 
    y  = * ( float * ) &i;
    y  = y * ( threehalfs - ( x2 * y * y ) );  // 1st iteration 
    // 2nd iteration, this can be removed
    // y  = y * ( threehalfs - ( x2 * y * y ) ); 

    return y;
}

2

分工不是问题，问题是分工后的协作是否统一和规范。
https://coolshell.cn/articles/5701.html

提高架构性能的常用技术包括：

缓存系统：通过引入缓存系统，可以有效提高系统的访问能力。从前端浏览器、网络到后端服务，包括底层的数据库、文件系统、硬盘和 CPU，都可以使用缓存来提高快速访问能力。在分布式系统中，需要建立一个缓存集群，其中一个缓存代理（Proxy）用于缓存的分片和路由。
负载均衡系统：负载均衡是水平扩展的关键技术，通过多台机器共同分担一部分流量请求来实现。负载均衡系统可以将流量请求分发到多个服务器上，从而提高系统的处理能力。
异步调用：异步系统通过使用消息队列对请求进行排队处理，可以平滑处理前端请求的峰值，后端根据自身处理速度来处理请求。这可以增加系统的吞吐量，但实时性会受到影响。同时，异步调用可能会引入消息丢失的问题，因此需要对消息进行持久化。然而，这也会带来状态管理和服务调度的难度。
数据分区和数据镜像：数据分区将数据按照特定方式分成多个区域（如地理位置），不同区域的数据可以分担不同区域的流量。这需要一个数据路由中间件，但也会导致跨库的关联查询和跨库事务变得非常复杂。数据镜像则是将一个数据库镜像成多份相同的数据，这样就不需要数据路由中间件。可以在任意节点上进行读写操作，内部会自动同步数据。然而，数据镜像的最大问题是数据一致性。

提高架构稳定性的常用技术包括：

服务拆分：服务拆分的目的是为了隔离故障和重用服务模块。但拆分后会引入服务调用间的依赖问题。
服务冗余：通过服务冗余可以消除单点故障，并支持服务的弹性伸缩和故障迁移。然而，对于有状态的服务来说，冗余会增加复杂性，例如在弹性伸缩时需要考虑数据的复制或重新分片，以及迁移数据到其他机器上。
限流降级：当系统承受不住压力时，可以通过限流或功能降级来停止一部分服务或拒绝一部分用户，以确保整个架构的稳定性。这些技术属于保护措施。
高可用架构：高可用架构通常从冗余架构的角度来保障可用性，例如多租户隔离、灾备多活或数据复制保持一致性的集群。目标是避免单点故障。
高可用运维：高可用运维指的是在DevOps中的持续集成/持续部署（CI/CD）。良好的运维应该包含流畅的软件发布管线，其中包括充分的自动化测试、灰度发布以及对线上系统的自动化控制。这样可以最大限度地减少计划内或非计划内的宕机时间。

全栈监控主要包括三个层次的监控：

基础层监控：监控主机和底层资源的状态，例如CPU、内存、网络吞吐、硬盘I/O、硬盘使用等。
中间层监控：监控中间件层的状态，例如Nginx、Redis、ActiveMQ、Kafka、MySQL、Tomcat等。这些监控可以帮助了解中间件的性能和稳定性。
应用层监控：监控应用层的使用情况，包括HTTP访问的吞吐量、响应时间、返回码、调用链路分析、性能瓶颈等。同时还包括对用户端的监控，以了解用户的行为和反馈。

如何做出一个好的监控系统

服务调用链跟踪。实践有 Google Dapper 系统、开源 Zipkin
服务调用时长分布
服务的 TOP N 视图
数据库操作关联
服务资源跟踪

https://research.google.com/pubs/pub36356.html
CMDB
服务的生命周期通常包含以下几个状态：
1. Provision（供应）：表示正在供应一个新的服务，即服务的创建和准备阶段。
2. Ready（就绪）：表示服务成功启动，已准备好接收请求和提供功能。
3. Run（运行）：表示服务通过了健康检查，处于正常运行状态。
4. Update（升级）：表示服务正在进行升级操作，可能是软件版本的更新或配置的修改。
5. Rollback（回滚）：表示服务正在执行回滚操作，即恢复到之前的稳定状态。
6. Scale（伸缩）：表示服务正在进行伸缩操作，可以是扩容（Scale-out）或缩容（Scale-in）。
7. Destroy（销毁）：表示服务正在被销毁，即结束该服务的运行。
8. Failed（失败）：表示服务处于失败状态，无法正常运行或提供功能。
VersionSet
https://eprints.qut.edu.au/622/1/SOD_(revised).pdf

https://coolshell.cn/articles/17459.html

下面这三件事是 PaaS 跟传统中间件最大的差别。

服务化是 PaaS 的本质。软件模块重用，服务治理，对外提供能力是 PaaS 的本质。
分布式是 PaaS 的根本特性。多租户隔离、高可用、服务编排是 PaaS 的基本特性。
自动化是 PaaS 的灵魂。自动化部署安装运维，自动化伸缩调度是 PaaS 的关键。

分布式经典资料如下：

基础理论：
- CAP 定理
- FLP 不可能性结果
经典资料：
- "Fallacies of Distributed Computing"
- "Distributed systems theory for the distributed systems engineer"
- "An introduction to distributed systems"
- "Distributed Systems for fun and profit"
- "Distributed Systems: Principles and Paradigms"
- "Scalable Web Architecture and Distributed Systems"
- "Principles of Distributed Systems"
- "Making reliable distributed systems in the presence of software errors"
- "Designing Data Intensive Applications"

逻辑钟和向量钟

Gossip 协议

3

CNCF（Cloud Native Computing Foundation，云原生计算基金会）

Service Mesh
http://philcalcado.com/2017/08/03/pattern_service_mesh.html
https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing
Service Mesh 开源软件是 Istio 和 Linkerd

https://github.com/cer/event-sourcing-examples

读写分离 CQRS
分库分表 Sharding

https://www.slideshare.net/MikeyCohen1/edge-architecture-ieee-international-conference-on-cloud-engineering-32240146

边缘计算的关键技术如下：

API Gateway
Serverless/FaaS

目前比较流行的几个开源项目包括：

Serverless Framework（https://www.serverless.com）：一个跨云平台的框架，用于构建和部署无服务器应用程序。它提供了简化的方式来管理基于事件驱动的函数计算。
Fission: Serverless Functions for Kubernetes（https://fission.io）：一个在 Kubernetes 上构建的无服务器函数计算平台。它允许开发人员以函数的形式部署和运行代码，自动处理扩缩容和资源管理。
OpenLambda（https://open-lambda.org）：一个开源的无服务器计算平台，旨在提供高性能和低延迟的函数执行环境。它支持多种编程语言和灵活的部署选项。
OpenFaaS（https://www.openfaas.com）：一个开源的函数即服务（FaaS）平台，构建在容器技术上。它提供简单的方式来部署和管理函数，并具有强大的扩展性和可插拔性。
IronFunction（https://github.com/iron-io/functions）：一个用于构建和运行无服务器函数的开源平台。它支持多种编程语言和事件触发器，并提供了弹性的计算资源管理。