-
Notifications
You must be signed in to change notification settings - Fork 0
/
Copy pathindex.html
352 lines (286 loc) · 32.5 KB
/
index.html
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
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
<!DOCTYPE html>
<html lang="zh-cn">
<head>
<meta charset="utf-8">
<meta http-equiv="X-UA-Compatible" content="IE=edge,chrome=1">
<title>Noumenon </title>
<meta name="HandheldFriendly" content="True">
<meta name="MobileOptimized" content="320">
<meta name="viewport" content="width=device-width,minimum-scale=1">
<meta name="generator" content="Hugo 0.52" />
<META NAME="ROBOTS" CONTENT="NOINDEX, NOFOLLOW">
<link href="/dist/css/app.955516233bcafa4d2a1c13cea63c7b50.css" rel="stylesheet">
<link href="https://cicirori.github.io/posts/index.xml" rel="alternate" type="application/rss+xml" title="Noumenon" />
<link href="https://cicirori.github.io/posts/index.xml" rel="feed" type="application/rss+xml" title="Noumenon" />
<meta property="og:title" content="Posts" />
<meta property="og:description" content="" />
<meta property="og:type" content="website" />
<meta property="og:url" content="https://cicirori.github.io/posts/" />
<meta property="og:updated_time" content="2018-12-06T17:07:14+08:00"/>
<meta itemprop="name" content="Posts">
<meta itemprop="description" content="">
<meta name="twitter:card" content="summary"/>
<meta name="twitter:title" content="Posts"/>
<meta name="twitter:description" content=""/>
</head>
<body class="ma0 avenir bg-near-white">
<header>
<div class="pb3-m pb6-l bg-black">
<nav class="pv3 ph3 ph4-ns" role="navigation">
<div class="flex-l justify-between items-center center">
<a href="https://cicirori.github.io/" class="f3 fw2 hover-white no-underline white-90 dib">
Noumenon
</a>
<div class="flex-l items-center">
<div hidden>
<span id="new-window-0">Opens in a new window</span>
<span id="new-window-1">Opens an external site</span>
<span id="new-window-2">Opens an external site in a new window</span>
</div>
</div>
</div>
</nav>
<div class="tc-l pv3 ph3 ph4-ns">
<h1 class="f2 f-subheadline-l fw2 light-silver mb0 lh-title">
Posts
</h1>
</div>
</div>
</header>
<main class="pb7" role="main">
<article class="pa3 pa4-ns nested-copy-line-height nested-img">
<main class="cf ph3 ph5-l pv3 pv4-l f4 tc-l center measure-wide lh-copy mid-gray"></main>
<section class="flex-ns flex-wrap justify-around mt5">
<div class="relative w-100 w-30-l mb4 bg-white"><div class="relative w-100 mb4 bg-white nested-copy-line-height">
<div class="bg-white mb3 pa4 gray overflow-hidden">
<span class="f6 db">Posts</span>
<h1 class="f3 near-black">
<a href="/posts/manjaro%E5%AE%89%E8%A3%85%E9%85%8D%E7%BD%AE%E8%B8%A9%E5%9D%91/" class="link black dim">
Manjaro安装配置踩坑
</a>
</h1>
<div class="nested-links f5 lh-copy nested-copy-line-height">
其实manjaro和arch的英文社区上都讲的很清楚, 推荐看英文原版资料.
制作USB安装器 参考资料 : Manjaro 官方User Guide
官网下载镜像 Linux下推荐通过命令行制作 插上用于制作安装盘的U盘 查看U盘盘符. sudo fdisk -l. 写入镜像: sudo dd if=manjaro-xfce-18.0-stable-x86_64.iso(替换成你下载的文件的名字) of=/dev/(这里替换成你上面的查到的盘符) bs=4M Windows推荐使用Rufus: 选择你要用于制作安装盘的U盘. 在Boot selection, 点击Select选择下载的Manjaro镜像, 点击Start, 然后在出现的窗口中选择DD Image 方式. 进入Live CD与安装 参考链接 :
https://gist.github.com/oguzkaganeren/502360965a9bda12e958de2d9b0c9dab https://gist.github.com/mauri870/5a54e415140875b9150ca31c491811f6 https://www.bountysource.com/issues/33991302-laptop-freezes-when-starting-x11-and-discrete-graphics-are-off 如果能正常进入的话可以忽略这一步, 但是有的机器会出现问题, 卡在命令行界面. 我们只要在内核启动参数添加 systemd.mask=mhwd-live.service 即可.
如果进入Live CD出现问题那么需要一些操作才能顺利安装, 修改/lib/calamares/modules/mhwdcfg/main.py :
def run(): """ Configure the hardware """ mhwd = MhwdController() # return mhwd.run() return None # 新添这行 并注释掉上一行 然后安装即可.
</div>
</div>
</div>
</div>
<div class="relative w-100 w-30-l mb4 bg-white"><div class="relative w-100 mb4 bg-white nested-copy-line-height">
<div class="bg-white mb3 pa4 gray overflow-hidden">
<span class="f6 db">Posts</span>
<h1 class="f3 near-black">
<a href="/posts/%E8%AE%BE%E8%AE%A1%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0%E4%BA%94/" class="link black dim">
设计分布式系统读书笔记（五）
</a>
</h1>
<div class="nested-links f5 lh-copy nested-copy-line-height">
函数与事件驱动处理 我们之前看到的系统设计都是为了长期运行的功能，服务器总是在线，这些模式对于那些处于高负载，占据大量内存和磁盘的服务来说是合适的。但是还有一类应用，可能需要在线的时间很短，或者只需要处理单一请求，或者只需要对每个时间响应。这种类型的请求或者叫事件驱动应用设计最近在大规模公有云上非常流行，厂家为此提出了FaaS（函数/功能即服务）。时间再往后推一点的最近，FaaS在私有云或者物理机器上也开始流行。
大多数时FaaS指无服务器（Serverless）计算，这么说也没什么错，但是广义的无服务计算和事件驱动FaaS并不是完全相同的概念。比如一个多用户容器（CaaS）是无服务器的，但是不是事件驱动的。一个开源的FaaS跑在你自己拥有管理的物理机上，这是事件驱动的但不是无服务器的。理解这两者的区别可以让你了解什么时候该使用事件驱动什么时候该使用无服务器，或者什么时候两者并用。
什么时候FaaS行得通 就像别的分布式系统的开发工具一样，FaaS也被用来当做一个非常通用的工具，但事实是FaaS也有它擅长和不擅长的领域。强行把一个工具到处使用，容易使得最后的系统复杂且脆弱。尤其是FaaS是一个比较新兴的工具，我们对它还有很多不了解的地方。
FaaS的优点 受益与FaaS最多的主要是开发者。它减少了从代码到服务的距离。FaaS使得不管你是在笔记本上还是通过浏览器，运行云上的代码总是那么简单。
同样的，部署好的代码可以实现自我管理和规模伸缩。当服务面临的流量变大时，更多的服务实例被创建，如果一个函数在一台机器上因为各种原因运行失败时，它会自动在另一台机器上重启。
最后，和容器一样，甚至比容器更粒度化。函数是无状态的，因此你建立在函数上的任何系统都是天生内在模块化与低耦合的。但是解耦既是优点又是缺点，下面我们会谈论这个。
FaaS面临的挑战 如同上一段所描述的，构建一个FaaS服务迫使你把你的服务解耦。每个函数都是独立的，唯一的交流渠道是网络，每个函数实例不能有本地内存，所有的状态都要存在存储服务里。这样造成的解耦可以提高灵活性与速度。但是也会显著的把一个服务的操作变得十分复杂。
尤其是，你很难对你的服务有一个全景式的了解，依此来决定各种函数之间的整合，了解哪些东西发生了错误。另外基于请求并且无服务器的函数的天性使得一些问题很难被检测。比如：
考虑一下当一个请求抵达任意一个其中的函数，就开启了无限的循环，只能等待请求超时或者耗尽内存。这样的错误真的发生在你的代码中时，很难检测到。
所以，现在当你使用FaaS是你必须要对你的系统进行详尽的监控，在错误造成更大影响之前发现它们。
FaaS不适合后台处理量大的任务，比如视频转码，压缩日志文件等等，这些任务一次请求需要你长期的运行。
FaaS也不太能满足需要大量数据的任务，因为FaaS需要把数据都调进内存，有很多任务，比如文档搜索的索引，需要的数据量相当巨大。即使用一个相对快的存储层，FaaS也很难提供一个令人满意的延迟。
FaaS的应用
</div>
</div>
</div>
</div>
<div class="relative w-100 w-30-l mb4 bg-white"><div class="relative w-100 mb4 bg-white nested-copy-line-height">
<div class="bg-white mb3 pa4 gray overflow-hidden">
<span class="f6 db">Posts</span>
<h1 class="f3 near-black">
<a href="/posts/%E8%AE%BE%E8%AE%A1%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0%E5%9B%9B/" class="link black dim">
设计分布式系统读书笔记(四)
</a>
</h1>
<div class="nested-links f5 lh-copy nested-copy-line-height">
分片服务 和副本服务不同的是，副本服务的每个副本都具有完整的功能，可以响应每一个请求，分片服务中每个分片只能服务请求的一个子集，请求由一个负载均衡节点或者叫根节点分配到对应的分片。两种模式的不同如下图所示
复制模式通常用来构建无状态服务，分片模式用来构建有状态服务。
分片缓存 分片缓存是位于用户请求和实际的前端实现之间的缓存。
#### 为什么你可能需要分片缓存
对任何服务进行分片的主要原因是想要增加存储在这个服务的数据量。为了理解这一点我们看一个例子，假设我们有如下系统：每个缓存有10GB RAM 可用，并且可以提供100RPS（requests per second）。假设我们的服务一共有200GB可能返回的结果，需要1000RPS。很明显我们需要十个这样的cache来满足1000RPS，一个简单的实现方式是利用复制模式，就像之前讲的一样。但是这样的话每个我们只能达到5%的容量。如果我们利用一个10路的分片缓存，我们仍然能服务大概1000RPS，但是我们能达到50%的容量，这样缓存就被更好的利用了。
缓存在你的架构中的角色 我们之前没有提过的是，缓存对你的应用性能，可靠性和稳定性的影响。简单来说，一个我们需要考虑的重要问题是，如果缓存故障，那么对你的用户和服务会产生什么影响。
在复制模式中这可能是不问题但是在分片模式中情况就有了变化。因为一个特定的用户或者特定的请求总被映射到同一个分片，所以缓存会一直miss直到故障恢复。
你的缓存性能由命中率（hit rate）决定，假设你有一个接受请求层一次具有1000RPS，超出这个范围的系统会开始返回HTTP 500 错误。如果你在服务之前放一个命中率50%的缓存，那么1000RPS会提升到2000RPS。其中一半请求会由缓存处理，剩下一半由后端处理。在这个例子下，如果你的缓存故障那么一半的用户请求都会失败，所以，尽量把请求控制在1500RPS而不是跑满，这样你可以提供一半的缓存故障下的稳定性。
除了每单位时间能够处理的请求之外，延迟对于你的系统来说也是一个重要的指标。缓存通常能显著的降低延迟。
### 分片，复制服务
我们举得例子大多是缓存，但是除此之外别的服务也可以受益于分片。比如大规模网络游戏，这样的游戏服务对于单机来说太大了，但是游戏里离得远的角色之间不会有什么互动，所以可以把整个游戏世界分片在多台服务器上。分片函数可以利用玩家的位置。
分散/聚集模式 和复制模式与分片模式一样，分散聚集模式也具有树形结构，由一个根结点分配请求。与之不同的是，分散聚集模式把请求同时分给所有的副本，每个副本做一部分工作，返回一个局部结果。由根节点合并计算结果。（有点类似map/reduce）。
分布式文件搜索：
</div>
</div>
</div>
</div>
<div class="relative w-100 w-30-l mb4 bg-white"><div class="relative w-100 mb4 bg-white nested-copy-line-height">
<div class="bg-white mb3 pa4 gray overflow-hidden">
<span class="f6 db">Posts</span>
<h1 class="f3 near-black">
<a href="/posts/%E8%AE%BE%E8%AE%A1%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0%E4%B8%89/" class="link black dim">
设计分布式系统读书笔记（三）
</a>
</h1>
<div class="nested-links f5 lh-copy nested-copy-line-height">
服务器模式 微服务 最近微服务变成了一个描述多节点分布式软件架构的流行词，微服务描述了一个系统由运行在不同进程上的组件组成，批次之间通过预定义的API进行交流。与微服务相对应的概念是宏系统，把所有的功能紧凑的放在一个应用中。
微服务有各种各样的好处，大多数情况下，微服务兼具可靠性和灵活性。微服务把一个应用分解成小片，每个小片专注于提供一种服务。这种模式有利于减小开发团队大小，使得开发更加灵活有方向性。
另外，API提供了不同团队、不同服务之间的解耦。每个团队的工作就是提供一个稳定可靠的API并利用其他团队提供的API进行自己服务的开发。这使得团队可以独立地规划自己的开发日程，保证了每个团队的迭代升级他们代码的能力。
最后，微服务提供的解耦很好的保证了拓展性。因为每个组件被分解成了微服务，这些微服务可以独立的升级拓展。在一个大型应用中，所有服务都以同步的步调升级或以同样的方式升级是很少见的。有些系统是无状态的可以简单的横向拓展，但是有些应用具有状态需要分片或者其他的方式来升级。
微服务当然也有缺点，它有两个主要的不足。一是因为微服务使得系统松散耦合，所以Debug的时候可能会变得异常困难，你很难简单的把一个单一的应用放进Debugger找出哪里出错了。除此之外，微服务难以设计和架构。一个微服务系统会使用多种服务间交流方式，多重不同的模式（同步、异步、消息传递等等），和多重不同的协作与控制模式。
这些困难是分布式模式的动力来源，如果一个微服务架构由一个well-known的模式所指导构建，那么我们就有很多前人的经验可以使用。开发者也可以更好的Debug这些微服务。
重复负载均衡服务 最简单也是最为人知的分布式模式是重复负载均衡服务（replicated load-balanced service）。
无状态服务 无状态服务不要求我们保存状态，在最简单的无状态服务中，甚至每个单独的请求都能被路由到不一样的服务实例。
无状态服务的例子包括静态内容服务器和从数量庞大的后端接受聚合请求的中间件系统。
无状态系统提供了冗余和拓展，不管你的服务多小，你都需要至少两个副本来提供高可用服务。我们假设一个看似可用性很高的服务，它的在线率99.9%，这意味着一天有一分钟二十四秒的宕机时间，我们增加一个副本，我们就可以把宕机时间缩短到3.6秒。
随着业务增长，服务容量需要拓展的时候，我们可以通过简单地横向添加副本来实现。
实现负载均衡探针 健康检查总是一件重要的事情，我们利用它可以发现不能正常提供服务的容器并及时重启它。于此相对的具有就绪探针（readiness probe）可以让负载均衡知道那些容器可以正常的提供服务并将请求分发给它。一个后端服务需要与数据库通信加载插件或者从网络下载服务文件，在此期间它们可能是alive的但是并非准备就绪的。
会话追踪服务 之前的例子针对无状态复制模式，但是这并非总是最佳的选择。很多时候我们系统一个特定用户的请求总是与一台特定的机器链接。比如我们可以借此保持更高的内存命中率。
通常，会话追踪一般通过hash资源与IP地址来决定哪个服务器服务哪个请求。所以只要请求的资源不变，ip不变，所有的请求都会被发到同样的副本。基于IP的会话追踪通常在内部IP的情况下工作良好，但是在外部IP情况在因为有NAT的存在则不是那么乐观，在这种情况下，应用层追踪（比如cookies）更适用。
应用层重复服务 上面的例子都工作在网络层，但是许多应用都使用HTTP通信。
缓存层 缓存层存在于用户与后端服务之间，当两个用户请求同一个资源时，只有一个请求会被发往后端。
部署缓存 缓存可以简单的利用挎斗模式来实现。
实现非常简单，它有一些坏处，你的服务与缓存拓展是同步的。比如你设计了10G的缓存总量，那么十个1G的缓存并不如两个5G来的好用。后者的命中率会高于前者。
因此我们有如下设计：
SSL终端 varnish是不支持SSL的但是nginx可以所以我们可以把HTTPS流量通过nginx中转给varnish。
</div>
</div>
</div>
</div>
<div class="relative w-100 w-30-l mb4 bg-white"><div class="relative w-100 mb4 bg-white nested-copy-line-height">
<div class="bg-white mb3 pa4 gray overflow-hidden">
<span class="f6 db">Posts</span>
<h1 class="f3 near-black">
<a href="/posts/%E8%AE%BE%E8%AE%A1%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0%E4%BA%8C/" class="link black dim">
设计分布式系统读书笔记（二）
</a>
</h1>
<div class="nested-links f5 lh-copy nested-copy-line-height">
## 大使模式
上图显示了一个典型的大使模式架构。大使模式的价值在于两点，首先构建一个模块化可复用的容器本身就具有价值，其次一个大使容器可以供多个应用容器使用，这种复用加快了开发进度也利于保证代码质量。我们接下来会提供大使模式的几个例子。
### 利用大使作服务分片
有时候数据量太大以至于单机无法完成任务，所以要对数据在存储层进行切片。当我们构建这么一个分片服务时，一个问题是我们怎么把分片上的数据进行整合，特别是在客户端的代码难以修改只能面向一个后端服务时。这时我们就可以使用大使模式，客户端与我们的大使容器通信，将请求进行处理发给分片服务上，将结果途径大使返回给应用。正如其名大使容器就是一个“外交代表”负责与外部的沟通。乍一看大使模式与挎斗模式有相似之处，但是与之不同的是，挎斗模式的挎斗容器像是应用容器的一个附件，有一一对应的关系，大使容器则可以与多个应用容器产生关系。
利用大使模式来做Service Brokering 当你想让一个应用变得在不同环境下可移动的时候，一个主要的挑战就是查找服务和配置。想象一个前端依赖MySQL来存储他的数据，在公有云中这个MySQL可能是以SaaS的形式提供的，因此将这个前端应用移动到私有云的时候我们需要一个新的虚拟机或者容器来运行这个MySQL服务。因此我们需要应用自动发现正确的MySQL服务，用来实现这一过程的系统就叫做Service Broker。
我们此时就可以利用一个大使容器，在应用看来他是一个运行在本地特定端口的SQL服务，所以应用只需要连接到它即可，实际的工作由大使与真正的服务提供程序通信。
利用大使做AB测试或者请求分流 在很多线上系统中，新功能的上线都要进行AB测试，大使模式可以很好的利用这一点。用户始终连接到大使容器，大使容器根据设置将这些连接分配给后端稳定的服务或者新上线需要测试的版本。
适配器模式 这一模式应该比较好理解，这里的适配器模式从理念上非常类似设计模式中的适配器模式。
现实世界中的应用开发是繁杂的，不同的人、不同的团队利用不同的语言、不同的框架来实现，一般都实现了不同的日志、监视等服务接口。
但是为了有效的对这些应用进行管理，你需要一个统一的界面/接口。适配器模式就是用于这种情况。
监视 实现应用的监视在实际生产中是非常必要的，通过了解应用消耗的CPU资源、内存等我们可以获得很多信息。这种接口有很多种比如syslog、windows上的事件追踪（etw）、Java中的JMX等等等等，这些标准需要统一，幸运地是这些工具商也都理解标准化的重要性，一般都提供了转换为通用监视标准的插件。我们可以利用适配器容器，通过这些不同的插件不同应用的不同标准监视信息统一化，提供给外界。
日志/健康 日志情况与监视基本类似。健康检查通常以脚本形式运行在容器中对应用容器进行检查并进行相关后续操作。
为什么我们不修改应用程序 而使用适配器 如果你是应用程序开发者，当然你可以在编写程序时使你的程序具有更好的通用性以适应多种情况。但是很多时候我们是使用别人开发的程序，处于技术或者商业的考虑，修改原应用程序远不及适配器模式来的高效与稳定，另外作为容器的好处适配器可以简单地实现复用。
</div>
</div>
</div>
</div>
<div class="relative w-100 w-30-l mb4 bg-white"><div class="relative w-100 mb4 bg-white nested-copy-line-height">
<div class="bg-white mb3 pa4 gray overflow-hidden">
<span class="f6 db">Posts</span>
<h1 class="f3 near-black">
<a href="/posts/%E8%BD%AC%E8%87%AAreddit-anki%E8%8B%B1%E6%96%87%E5%8D%A1%E7%BB%84%E6%90%9C%E9%9B%86/" class="link black dim">
[转自Reddit]Anki英文卡组搜集
</a>
</h1>
<div class="nested-links f5 lh-copy nested-copy-line-height">
https://www.reddit.com/r/Anki/comments/6z57zk/anki_decks_collection_mostly_englishenglish/
Decks Podcasts The English We Speak (345 notes) 6 Minute English (153 notes) Grammar English Grammar In Use Exercises (5885 notes) English Grammar In Use Activities (3601 notes) Advanced English Grammar In Use Activities (2500 notes) Vocabulary LDOCE6 Pictures (1504 notes) 6 Minute English Vocabulary (3962 notes) Outcomes Vocabulary Builder (5344 notes) The Unofficial Harry Potter Vocabulary Builder (3025 notes) Idioms Essential Idioms in English (468 notes) Illustrated Everyday Expressions with Stories (600 notes) Oxford Word Skills.
</div>
</div>
</div>
</div>
<div class="relative w-100 w-30-l mb4 bg-white"><div class="relative w-100 mb4 bg-white nested-copy-line-height">
<div class="bg-white mb3 pa4 gray overflow-hidden">
<span class="f6 db">Posts</span>
<h1 class="f3 near-black">
<a href="/posts/%E8%AE%BE%E8%AE%A1%E5%88%86%E5%B8%83%E5%BC%8F%E7%B3%BB%E7%BB%9F%E8%AF%BB%E4%B9%A6%E7%AC%94%E8%AE%B0%E4%B8%80/" class="link black dim">
设计分布式系统读书笔记（一）
</a>
</h1>
<div class="nested-links f5 lh-copy nested-copy-line-height">
Introduction 软件开发模式简史 算法编程的形式化 1962年，计算机编程的艺术一书横空出世，揭开了计算机科学发展的新篇章。本书谈论了算法本身，而不是面向某个特定程序的code。
OOP 随着计算机软件变得复杂，开发软件的人员逐渐增多。为了解决这个问题，OOP思想出现了。
开源软件的崛起 可能开源软件和分布式系统在开发模式上只有很小的相关，但是值得注意的是，现在所有的container技术都是由开源社区作为主要推动力的。
模式的价值 站在巨人的肩膀上
让我们的讨论建立在同样的话语体系上
易于复用的组件
单节点模式 单节点模式同样具有很多价值与应用，也是多节点的基础。
场景一 对不同需要的app分配不同得资源。并对资源进行调用。 场景二 不同的team协同工作，划分不同的工作空间。 场景三 易于测试、更新和部署。 Chapter 2 挎斗（sidecar）模式 sidecar模式中存在一个应用容器（application container）和挎斗程序（sidecar container），应用容器中跑的是应用的核心逻辑。挎斗容器增加（augment）或者改进（improve）应用容器。
实例1 给老旧的服务添加HTTPS 我们现在有一个老旧的web服务，当它编译的时候HTTPS还不流行，现在为了安全性考虑想要添加HTTPS，但是服务是在老版本的系统上build的，所以直接修改源代码是一个很艰难的工作。为此，我们添加一个sidecar容器，是一个SSL的代理，外部流量通过安全的方式连接到这个代理，然后不安全的http流量只在localhost上经过，我们的目标达成。
实例2 利用sidecar实现动态配置 另一个sidecar的常见应用是进行配置同步，许多应用利用本地文件来存储配置，譬如XML，JSON或者YANL。但是在云上我们有很强烈的通过API来修改访问这一配置的需求。为了实现这一功能，我们添加一个sidecar容器，和应用容器共享配置文件，我们允许通过API来和sidecar通信修改物理配置文件，修改完成后sidecar通过一定的方式通知应用容器刷新配置。
实例3 模块化应用容器 为了实现一个类似top命令的功能，我们可以给每个开发者实现一个HTTP/topz接口提供资源使用情况的读写，为了简化它，你可能想要实现一个基于语言的插件。但是就算这么做，你也不得不考虑多种语言并且，一旦有新的语言，这种方法也不能马上跟进。
我们可以部署一个sidecar容器和应用容器共享PID，这个topz容器可以内省所有的进程并提供一个持续更新的用户界面。
实例4 利用sidecar部署PaaS应用 我们可能想要实现这样一个PaaS，一旦我们把代码提交给git repo就可以自动化的上线新代码。
我们把我们需要更新代码的程序，比如一个Node.js服务器跑在应用容器里，另外开一个sidecar跑几行简单的循环git pull代码，这两个容器共享文件，就实现了我们想要的功能。
模块性 可复用性 为了实现好的模块性和可复用性。我们在开发的过程中需要关注这三个方面：
参数化你的容器 为你的容器制定API标准 为你的容器编写文档 参数化容器 把你的容器看做一个函数，考虑每个参数的意义。
定义每个容器的API 当然参数也是容器的一部分，除此之外还有容器对其他容器的调用、传统的HTTP和其它API。但是定义API的工作要提早进行，上线之后对API的更改不仅耗费精力，还可能会造成未知的后果。
为你的容器编写文档 不幸的是，现在给容器映像编写文档的工具非常之少。但是编写恰到好处详尽的文档仍然是必要的。有些在Dockerfile中已经定义的注释，比如EXPOSE **** 表示这个映像监听的端口。你还可以李荣LABEL直接添加matadata进你的映像。http://label-schema.org/rc1/这里介绍了一些LABEL的使用惯例。
</div>
</div>
</div>
</div>
<div class="relative w-100 w-30-l mb4 bg-white"><div class="relative w-100 mb4 bg-white nested-copy-line-height">
<div class="bg-white mb3 pa4 gray overflow-hidden">
<span class="f6 db">Posts</span>
<h1 class="f3 near-black">
<a href="/posts/%E5%85%B3%E4%BA%8E%E4%B8%89%E6%AE%B5%E8%AE%BA/" class="link black dim">
关于三段论
</a>
</h1>
<div class="nested-links f5 lh-copy nested-copy-line-height">
三段论在传统逻辑中，是在其中一个命题（结论）必然地从另外两个命题（叫做前提）中得出的一种推论。这个定义是传统的，可以宽松地从亚里士多德的《前分析篇》Book I, c. 1中推出来。希腊语“sullogismos”的意思是“演绎”。对传统意义上的三段论的详细描述参见直言三段论。
三段论由三个部分组成：大前提、小前提和结论，它在逻辑上是从大前提和小前提得出来的。大前提是一般性的原则。小前提是一个特殊陈述。在逻辑上，结论是从应用大前提于小前提之上得到的。
以上是维基百科对三段论的定义。大前提、小前提和结论，在我人生的前二十年一直没有怀疑过这个理论的正确性，甚至没有产生过一丝怀疑，这一切都是那么自然，就如同是不是不是（being is not is-not）一样（这个是黑格尔在他的《逻辑学》里搞辩证法的时候讲到的东西，有机会再和你们扯）。我一直觉得亚里士多德就凭这一个成就，就足以盖过他在各科教科书中干过的所有傻事（其实也都真不傻）。
终极命题 然而这种想法从我接触到哲学史开始改变。大前提-小前提-结论，在有限的范围内这个论证过程固然是没有问题的。但是在看哲学史的过程中，我对这个我曾经以为简洁，完备的颠扑不破的真理产生了怀疑。如果我们把它一直向前推，大前提、小前提都是由他们的大前提、小前提来保证正确性的，所以我们会一直追寻到一个地步，那就是纯粹的绝对真理，我们知性可以把握的绝对真理。绝对真理这样一个东西自然对于一个标榜理性高于一切、从小接受现代教育的人自然是不能接受的。我开始追溯我对理性那么强的信念来自于什么。我虽然可以把握到片面的三段论的正确性，并且以此来作为评判所有事情的底线原则，但是我当注意到上面说的问题时，我感觉自己就像生活在计算机里的虚拟人物，我世界里的一切都那么真实合理，但是它们都有一个我无法解释、不能想象的来源。
（在后来的AI课上我了解到了哥德尔不完备定理，简单来讲对于推演系统我们定义如下两个性质：1、完备性：所有系统产生的命题都可以根据推演系统给定的规则推演出来它的真值。2、一致性：推演系统推演出来的结果都是对的，不存在矛盾，比如不能1>2和2>=1同时为真（这个矛盾在一开始的推演系统中有定义，当然你完全可以定义一个不矛盾的系统）。那么我们有如下定理：任何一个表达力足够强不可能即完备又一致。具体证明我就不是很清楚了，但是这个很重要，让我觉得现代科学真是太好了，重新坚定信念好吧。）
</div>
</div>
</div>
</div>
<div class="relative w-100 w-30-l mb4 bg-white"><div class="relative w-100 mb4 bg-white nested-copy-line-height">
<div class="bg-white mb3 pa4 gray overflow-hidden">
<span class="f6 db">Posts</span>
<h1 class="f3 near-black">
<a href="/posts/%E5%88%A9%E7%94%A8gcp%E8%B4%9F%E8%BD%BD%E5%B9%B3%E8%A1%A1%E5%AE%9E%E7%8E%B0ipv6%E7%9A%84shadowsocks/" class="link black dim">
利用GCP负载平衡实现IPv6的shadowsocks
</a>
</h1>
<div class="nested-links f5 lh-copy nested-copy-line-height">
Shadowsocks 端口设置为GCP TCP负载平衡支持的端口 比如5222
GCP的负载平衡 先建立一个实例组 把要用的VM加进去
使用TCP负载均衡-从互联网到我的VM-多个区域(单个区域貌似会有点问题)-然后基本的配置都是默认 前端IP选择v6就可以
防火墙 这个点堵了我将近一年_(:з」∠)_ 从我本科改用GCP到今天才搞定 因为一开始出站入站规则都是0.0.0.0/0 全允许 所以根本没有想过这个事情 今天在研究为什么学校的网这么慢 又顺手折腾了一下 多建两条出入站规则 目标设置为指定的服务账号 目标服务帐号选自己的
附上我的配置截图 除了防火墙规则之外 需要注意运行状态检查是否成功 以我有限的经验运行状态检查成功基本就没问题了 主要还是防火墙 其他的部分可以参考网上其他的gcp load balance文章 太懒了_(:з」∠)_
因为折腾了一次就扔在那里了 没有仔细研究过 有不对的地方还请大佬们悉心指正
</div>
</div>
</div>
</div>
</section>
</article>
</main>
<footer class="bg-black bottom-0 w-100 pa3" role="contentinfo">
<div class="flex justify-between">
<a class="f4 fw4 hover-white no-underline white-70 dn dib-ns pv2 ph3" href="https://cicirori.github.io/" >
© 2018 Noumenon
</a>
<div>
<div hidden>
<span id="new-window-0">Opens in a new window</span>
<span id="new-window-1">Opens an external site</span>
<span id="new-window-2">Opens an external site in a new window</span>
</div>
</div>
</div>
</footer>
<script src="/dist/js/app.3fc0f988d21662902933.js"></script>
</body>
</html>