阅读要记-《左耳听风》

阅读要记-《左耳听风》

1

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

BOSS VS LEADER

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

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

  1. 统一分类的错误字典：在错误码或异常捕捉时，需要将错误进行分类，并统一定义相关的错误。建议在一个地方定义错误，比如使用HTTP的4XX表示客户端问题，5XX表示服务端问题。创建一个错误字典可以提高代码的可维护性和重用性。

  2. 同类错误的定义可扩展：通过面向对象的继承或接口多态的方式，可以定义同类错误，并方便地扩展已有的代码。这种方式能够更好地处理错误的分类和处理逻辑。

  3. 定义错误的严重程度：根据错误的严重程度，如Fatal（重大错误）、Error（资源或需求问题）、Warning（需要注意但不一定是错误）、Info（信息）、Debug（调试信息），来标识错误的级别。

  4. 使用错误码而非错误信息进行错误日志输出：在打印错误日志时，最好使用统一的格式，并使用错误码而非错误信息。错误码可以是一个能从错误字典中找到的关键字，有利于自动化监控和日志分析。

  5. 忽略错误需记录日志：在忽略错误时，最好记录相应的日志，否则会给维护带来困扰。对于同一个地方不断报错的情况，不建议每次都打印日志，而是记录错误以及出现的次数。

  6. 不要将错误处理逻辑用于业务逻辑：避免使用异常捕捉等错误处理方式来处理业务逻辑，应该使用条件判断。异常捕捉用于处理意外情况，而错误码用于处理可能发生的事情。

  7. 对于同类错误处理使用一致的模式：针对同类的错误处理，应该使用相同的模式，比如对于null对象的错误，要么都返回null并加上条件检查，要么都抛出NullPointerException。避免混用，以保持代码规范。

  8. 尽可能在错误发生的地方处理错误：在错误发生的地方处理错误可以简化调用者的逻辑。将错误尽早处理可以减少错误的传递和副作用。

  9. 向上返回原始错误：如果必须将错误返回给更高层进行处理，应该返回原始的错误而不是重新创建一个错误。这样可以保持错误的准确性和完整性。

  10. 错误处理时总是要进行清理：在处理错误时，需要进行清理已分配的资源，以确保程序的稳定性和资源管理的正确性。

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

魔数 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

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

  1. 缓存系统：通过引入缓存系统，可以有效提高系统的访问能力。从前端浏览器、网络到后端服务，包括底层的数据库、文件系统、硬盘和 CPU，都可以使用缓存来提高快速访问能力。在分布式系统中，需要建立一个缓存集群，其中一个缓存代理（Proxy）用于缓存的分片和路由。

  2. 负载均衡系统：负载均衡是水平扩展的关键技术，通过多台机器共同分担一部分流量请求来实现。负载均衡系统可以将流量请求分发到多个服务器上，从而提高系统的处理能力。

  3. 异步调用：异步系统通过使用消息队列对请求进行排队处理，可以平滑处理前端请求的峰值，后端根据自身处理速度来处理请求。这可以增加系统的吞吐量，但实时性会受到影响。同时，异步调用可能会引入消息丢失的问题，因此需要对消息进行持久化。然而，这也会带来状态管理和服务调度的难度。

  4. 数据分区和数据镜像：数据分区将数据按照特定方式分成多个区域（如地理位置），不同区域的数据可以分担不同区域的流量。这需要一个数据路由中间件，但也会导致跨库的关联查询和跨库事务变得非常复杂。数据镜像则是将一个数据库镜像成多份相同的数据，这样就不需要数据路由中间件。可以在任意节点上进行读写操作，内部会自动同步数据。然而，数据镜像的最大问题是数据一致性。

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

  1. 服务拆分：服务拆分的目的是为了隔离故障和重用服务模块。但拆分后会引入服务调用间的依赖问题。

  2. 服务冗余：通过服务冗余可以消除单点故障，并支持服务的弹性伸缩和故障迁移。然而，对于有状态的服务来说，冗余会增加复杂性，例如在弹性伸缩时需要考虑数据的复制或重新分片，以及迁移数据到其他机器上。

  3. 限流降级：当系统承受不住压力时，可以通过限流或功能降级来停止一部分服务或拒绝一部分用户，以确保整个架构的稳定性。这些技术属于保护措施。

  4. 高可用架构：高可用架构通常从冗余架构的角度来保障可用性，例如多租户隔离、灾备多活或数据复制保持一致性的集群。目标是避免单点故障。

  5. 高可用运维：高可用运维指的是在DevOps中的持续集成/持续部署（CI/CD）。良好的运维应该包含流畅的软件发布管线，其中包括充分的自动化测试、灰度发布以及对线上系统的自动化控制。这样可以最大限度地减少计划内或非计划内的宕机时间。

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

  1. 基础层监控：监控主机和底层资源的状态，例如CPU、内存、网络吞吐、硬盘I/O、硬盘使用等。

  2. 中间层监控：监控中间件层的状态，例如Nginx、Redis、ActiveMQ、Kafka、MySQL、Tomcat等。这些监控可以帮助了解中间件的性能和稳定性。

  3. 应用层监控：监控应用层的使用情况，包括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

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

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

分布式经典资料如下：

  1. 基础理论：

    • CAP 定理
    • FLP 不可能性结果

  2. 经典资料：

    • "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，云原生计算基金会）

  • 读写分离 CQRS
  • 分库分表 Sharding
  • CDN

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

  • API Gateway
  • Serverless/FaaS

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

  1. Serverless Framework（https://www.serverless.com）：一个跨云平台的框架，用于构建和部署无服务器应用程序。它提供了简化的方式来管理基于事件驱动的函数计算。

  2. Fission: Serverless Functions for Kubernetes（https://fission.io）：一个在 Kubernetes 上构建的无服务器函数计算平台。它允许开发人员以函数的形式部署和运行代码，自动处理扩缩容和资源管理。

  3. OpenLambda（https://open-lambda.org）：一个开源的无服务器计算平台，旨在提供高性能和低延迟的函数执行环境。它支持多种编程语言和灵活的部署选项。

  4. OpenFaaS（https://www.openfaas.com）：一个开源的函数即服务（FaaS）平台，构建在容器技术上。它提供简单的方式来部署和管理函数，并具有强大的扩展性和可插拔性。

  5. IronFunction（https://github.com/iron-io/functions）：一个用于构建和运行无服务器函数的开源平台。它支持多种编程语言和事件触发器，并提供了弹性的计算资源管理。

4

  • 拜占庭容错系统研究中的三个重要理论：CAP、FLP、DLS

5

6

沟通：引导、倾听、共情、高维和反馈。

  • 引导，用提问的方式，“倒逼”员工找到答案，从而提高员工的参与感和成就感。
  • 倾听，心态平和，毫无偏见，全面接收和理解对方的信息，而不是只听自己想听的信息。
  • 共情，换位思考，站在对方立场设身处地思考和处理问题，动之以情，晓之以理。
  • 高维，提升自己的格局观，能从全局利益、长远利益思考问题，解决问题。
  • 反馈，建立反馈机制，及时发现问题、解决问题，形成正向循环。
posted @ 2023-07-02 13:25  sha0dow  阅读(241)  评论(0)  编辑  收藏  举报