发表于

所谓猴子补丁就是在程序运行的过程中动态的修改一些模块、类、方法，而不是在静态代码中去修改相应的实现

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
package main
import (
    "fmt"
    "os"
    "strings"
    "bou.ke/monkey"
)
func main() {
    monkey.Patch(fmt.Println, func(a ...interface{}) (n int, err error) {
        s := make([]interface{}, len(a))
        for i, v := range a {
            s[i] = strings.Replace(fmt.Sprint(v), "hell", "*bleep*", -1)
        }
        return fmt.Fprintln(os.Stdout, s...)
    })
    fmt.Println("what the hell?") // what the *bleep*?
}

golang monkey
http://xiaorui.cc/archives/5128
https://studygolang.com/articles/11296

发表于 
基本结构
    trie树，即字典树，又称单词查找树或键树，是一种树形结构，是一种哈希树的变种。典型应用是用于捅进和排序大量的字符串，所以经常被搜索引擎系统用于文本词频统计

    优点
        最大限度的减少无畏的字符串比较，查询效率比哈希表高
    ![](http://pic.aipp.vip/20200404194244.png)
    核心思想
        空间换时间，利用字符串的公共前缀来降低查询时间的开销以达到提高效率的目的

    基本性质
        根节点不包含字符，除根节点外每一个节点都只包含一个字符
        从根节点到某一节点，路径上经过的字符连接起来，为该节点对应的字符串
        每个节点的所有子节点所有的字符都不相同

1
2
3
4
5
6
7
8
9
10
11
12
13
14
const SIZE = 100;
type TrieNode struct{
    children []*TrieNode
    isEndOfWord bool
}
func NewTrieNode()*TrieNode{
    return &TrieNode{
        child: make([]*TrieNode,SIZE),
        isEndOfWord: false
    }
}

发表于 
汇编

通用寄存器使用惯例
rbp 栈帧指针寄存器，用于标识当前栈帧的起始位置
rsp 栈指针寄存器，通常指向栈顶位置，堆栈的pop和push操作就是通过改变rsp的值即移动堆栈指针位置来实现的
rax 结果寄存器，通常用于存储函数调用的返回结果，同时也用于乘法和除法指令中。

[](https://zhuanlan.zhihu.com/p/27339191)
![](http://pic.aipp.vip/20200104165359.png)


    EAX 是"累加器"(accumulator), 它是很多加法乘法指令的缺省寄存器。

    EBX 是"基地址"(base)寄存器, 在内存寻址时存放基地址。

    ECX 是计数器(counter), 是重复(REP)前缀指令和LOOP指令的内定计数器。
  EDX 则总是被用来放整数除法产生的余数。
ESI/EDI分别叫做"源/目标索引寄存器"(source/destination index),因为在很多字符串操作指令中, DS:ESI指向源串,而ES:EDI指向目标串.

        EBP是"基址指针"(BASE POINTER), 它最经常被用作高级语言函数调用的"框架指针"(frame pointer). 在破解的时候,经常可以看见一个标准的函数起始代码:


函数的调用
    子函数调用时，调用者与被调用者的栈帧结构如下图所示：
    ![](http://pic.aipp.vip/20200105034810.png)

    在子函数调用时，执行的操作有：父函数将调用参数从后向前压栈 -> 将返回地址压栈保存 -> 跳转到子函数起始地址执行 -> 子函数将父函数栈帧起始地址（%rpb） 压栈 -> 将 %rbp 的值设置为当前 %rsp 的值，即将 %rbp 指向子函数栈帧的起始地址。

函数的返回
![](http://pic.aipp.vip/20200105034946.png)
函数返回时，我们只需要得到函数的返回值（保存在 %rax 中），之后就需要将栈的结构恢复到函数调用之差的状态，并跳转到父函数的返回地址处继续执行。由于函数调用时已经保存了返回地址和父函数栈帧的起始地址，要恢复到子函数调用之前的父栈帧，我们只需要执行以下两条指令：


### 指令和运算

#### 计算机指令

#### 指令跳转

#### 函数调用

stack overflow
    栈空间溢出，通常两个原因
    1.调用层级过多，导致stack无法容纳
    2.栈上分配了过大的数据

    优化方式
    1.编译器自动优化，增加-O参数进行函数内联


#### ELK和静态链接


目标文件


#### 程序内存装载


查看内存页大小
$ getconf PAGE_SIZE


#### 动态链接

采用共享链接库方式公用大量公共库，减少内存使用，二来还可以动态编译
有两种方式实现动态链接
1.PLT(Procedure Link Table)+GOT(Global Offset Table)


#### 二进制编码

　　正数的原码、反码和补码都相同。

　　负数原码和反码的相互转换：符号位不变，数值位按位取反。

　　负数原码和补码的相互转换：符号位不变，数值位按位取反,末位再加1。

发表于 
11-12 nginx
    http框架初始化
        http框架
            由核心模块ngx_http_module、两个http模块ngx_http_core_module、ngx_http_upstream_module构成
        http框架要完成那些工作
            1.处理所有http块配置项
            2.监听web端口处理连接时间、可读时间、可写事件等
            3.有状态机来分析接收到的TCP字符是否是完整的HTTP包
            4.根据接收到的URI和HTTP头按照所在阶段准确分发到某一个http模块，从而调用它的回调方法来处理请求
            5.向HTTP模块提供必要工具方法，可以处理网络I/O、磁盘I/O
            6.提供upstream机制帮助http模块访问第三方服务
            7.提供subrequest机制帮助http模块实现子请求
        介入content阶段两种方式(381页)
            如果希望方法应用于所有用户请求，应该在ngx_http_module_t接口的postconfiguration方法宏，向ngx_http_core_main_conf_t结构体的phases[NGX_HTTP_CONTENT_PHASE]动态数组中添加ngx_http_handler_pt处理方法
            如果希望方法仅应用于URL匹配的某些用户请求，应该在一个location下配置项的回调方法中，把ngx_http_handler_pt方法设置到ngx_http_core_loc_conf_t结构体的handler中
        http是如何介入事件处理的
            ngx_http_block(配置项http的解析方法)
            ngx_http_optimize_servers
            ngx_http_init_listening
            ngx_http_add_listening(将监听端口的handler设置为ngx_http_init_connection)
            ngx_http_init_connection(新连接建立后，调用监听端口的handler，  ls->handler(c))
        http框架的初始化流程(382页)

发表于 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
tcp window
慢启动cwnd
<!--more-->
如何学习一个东西
    特点
    为什么
    如何实现
    优缺点
技术能力
业务能力
通用能力(沟通能力，表达能力，学习能力)
提高业绩产出
三层架构
    三层架构是一种分层式软件架构设计理念，通常意义上将程序划分为:表现层、业务逻辑层、数据持久化层
项目流程: 评审->设计->开发->测试->部署
架构的重要性
    对于程序需求我们可以分为应用功能性需求和非功能性需求。架构的重要习惯在于它影响了应用的非功能性需求，也成为质量属性，最显著的就是软件的可维护性、可测试性、可部署性和可扩展性
    架构设计的核心是决策，你需要决策到底是单体架构还是微服务架构更适合你的应用程序，当进行这些决策时，会存在大量的权衡和取舍
单体应用(参考5页图1-2)
    优点
        易于程序大犯规更改
        运维成本低
    缺点
        复杂度过高，很少有人能全面能掌握每个功能模块
        交付周期长且都容易出问题，每次都需要对所有逻辑做全面测试(通常很难做到)
        无法独立部署，某台机器都必须包含完整程序模块
        可扩展性差，要求扩展资源满足所有模块的需求
        可能导致被动长期依赖某个过时的技术栈
程序设计思想
    高内聚，低耦合
微服务(参考10页图1-7)
    基本概念
        AKF扩展立方体
            X轴扩展(水平复制)
            Y轴扩展(根据功能拆分，服务本质上是一个五脏俱全的应用程序，必要时可以借助X或Y轴方式进行扩展)
            Z轴扩展(数据分区，通过类似客户ID这样的请求属性路由请求，将相似的数据分区进行扩展，每个实例负责数据的一部分子集)
        与模块化的关系
            模块化是开发大型复杂应用的基础，面向的是单体应用，然而随着时间推移及反复迭代，单体应用会蜕变为一个大泥球
            微服务架构使用服务作为模块化的单元。服务API为它字舍内构件一个无法逾越的边界，你无法越过API去访问服务内部的类，算是模块化的另一种体现
        与SOA的关系
            SOA通常面向较大的单体应用，服务间通信使用智能管道(例如ESB)，往往采用重量级协议，数据管理采用全局数据模型并共享数据库
            微服务通常面向较小的服务，使用哑管道(例如消息代理、服务间点对点通信，使用REST或gRPC等轻量级协议)，每个服务都有自己的数据模型和数据库
    基本特点
        松耦合
            每个服务之间都是松耦合的，他们仅通过API进行通信，实现这种松耦合的方式之一，是每个服务都拥有自己的私有数据库
        每个服务都可以独立开发、测试、部署、扩展
    优缺点
        优点
            每个服务复杂度相对较低易维护
            服务可独立测试，有更好的容错性
            服务可独立部署，可以快速迭代
            服务可独立扩展
            微服务架构可以实现团队自治
            更容易试验和采纳新的技术
        弊端
            服务拆分定义是一项挑战
            分布式系统带来各种复杂性，使得开发、测试部署变得更困难
            当部署跨多服务功能时需要协调更多团队
    模式
        对于软件开发者来说，需要客服情绪化的本能，找到一种程序设计的方法，这个方法便是采用模式。
        模式是针对特定上下文中发生问题的可重用解决方案，我们把解决类似问题的模式组成一组模式。关系相关的模式集合形成所谓的模式语言，模式语言中的模式共同决定特定领域中的问题
        微服务架构模式语言(24页)
            服务拆分相关模式
                根据业务能力拆分
                根据子域拆分(DDD)
            通信相关模式
                通过微服务架构构建的应用程序是分布式系统，因此进程间通信(IPC)是微服务架构的重要组成部分，架构师需要就服务间与外部世界进行通信做出各种架构和设计决策，分为以下5组
                    通信风格: 使用哪一类进程间通信机制
                    服务发现: 客户端如何获取服务具体实例的IP地址
                    可靠性:服务不可用情况下，如何确保服务间可靠通信
                    事务性消息: 如何将消息发送、事件发布这样的动作与更新业务数据的数据库事务集成
                    外部API: 应用程序的客户端如何与服务进行通信
            实现事务管理的数据一致性相关模式
            在微服务架构中查询数据的相关模式
                服务和数据一一对应会带来一个挑战:有些服务需要从多个服务的数据源获取数据(传统采用SQL JOIN方式完成)，服务数据仅可以通过API方式访问，所以我们不能直接针对服务数据库执行分布式查询，多数情况下我们需要使用命令查询职责隔离(CQRS)的方式来维护一些重要和常用的查询数据视图
            服务部署的相关模式
                serverless
                容器、虚拟机
            可观测性的相关模式
                以下模式可用来设计具备可观测性的服务
                    健康检查API:可返回服务健康状态的api
                    日志聚合: 将服务产生的日志写入一个集中式日志服务器，这个服务器可以提供日志搜索，也可以根据日志情况触发报警
                    分布式追踪: 为每个外部请求分配一个唯一的ID，用于在各个服务间追踪外部请求
                    异常追踪: 把程序异常发送到异常跟踪服务，这个服务会排除重复异常，给开发者发送警告并跟踪每一个异常的解决
                    应用指标: 供维护使用的指标，例如计数器等，导出到指标服务器
                    审计日志: 记录用户的行为
            实现服务自动化测试的相关模式
                消费端驱动的契约测试: 验证服务满足客户端所期望的功能
                消费端契约测试: 验证服务的客户端可以正常与服务通信
                服务组件测试: 在隔离的环境中测试服务
            解决基础设施和边界问题的相关模式
                在微服务架构中，每个服务都必须实现许多与基础设施相关的功能，包括可观测性模式和服务发现模式，还必须实现外部化配置模式，该模式在运行时向服务提供数据库凭据等配置参数。在开发新服务时，更好的方式是在处理这些问题时应用微服务基底模式，这样在现有成熟的基底框架上构建服务
            安全相关的模式
                在微服务架构中，用户身份验证的工作通常由API Gateway完成，然后它必须将有关用户的信息传递给它调用的服务。常见的解决方案是应用访问令牌模式(例如JWT)
    微服务之上:流程和组织
        除了拥有正确的架构外，成功的软件开发还需要在架构、流程和组织方面做一些工作(p30,图1-16)
        进行软件开发和交付的组织
            应用程序的架构往往反映了开发它的组织的结构，因此，反向应用康威定律并设计你的企业组织，使其结构与微服务的架构一一对应，可以确保你的开发团队与服务一样松耦合
        进行软件开发和交付的流程
            微服务架构中需要积极实践持续交付和持续部署
            持续交付的一个关键特征是软件总是随时可以交付，它依赖高水平的自动化，包括自动化测试
    分布式数据管理的架构模式
    针对微服务架构程序的有效测试逻辑
    微服务架构程序的部署方式
    将单个应用重构为微服务架构的策略
开发
测试
部署
可扩展性
技术栈

发表于

数据的逻辑结构
集合: 元素间除同属一个集合外，无其他关系
线性结构: 一个对一个，如线性表、栈、队列
树形结构: 一个对多个，如树
图结构: 多个对多个，如图

阅读全文 »

发表于

类型
定义
简短模式
简短模式并不总是重新定义变量，也饿能是部分退化的赋值操作
退化赋值的前提条件是: 最少有一个新变量被定义，且必须是同一作用域
常量
值类型
引用类型
slice
map
channel
function
interface
别名
byte int8
rune int32
别名可以直接赋值
自定义类型
无法继承基础类型的方法，与基础类型是完全无关的两个类型
类型转换
(转换类型)()

阅读全文 »