蓝绿发布

蓝绿部署，Blue-Green Deployment，蓝/绿部署是一种部署策略，您可以在其中创建两个独立但相同的环境。一个环境（蓝色）正在运行当前的应用程序版本，一个环境（绿色）正在运行新的应用程序版本。如果部署失败，使用蓝/绿部署策略可通过简化回滚过程来提高应用程序可用性并降低部署风险。在绿色环境上完成测试后，将实时应用程序流量定向到绿色环境，而弃用蓝色环境。

蓝绿色的部署还为您提供了一种快速回滚的方法 - 如果出现任何问题，您将路由器切换回蓝色环境。在绿色环境实时时，仍然存在处理错过交易的问题，但是根据您的设计，您可能能够以使两种环境的交易将交易送达，以使蓝色环境作为绿色现场时的备份。或者，您可能能够在剪切之前将应用程序放在只读模式下，在仅阅读模式下运行一段时间，然后将其切换为读取版模式。这可能足以解决许多出色的问题。

这两个环境需要不同，但尽可能相同。在某些情况下，它们可能是不同的硬件，或者它们可以是在相同（或不同）硬件上运行的不同虚拟机。它们也可以是单个操作环境，该环境将两个切片的单独的IP地址分配到单独的区域中。

一旦将绿色环境生存并对它的稳定性感到满意，然后将蓝色环境用作登台环境，用于下一次部署的最终测试步骤。当您准备好下一个版本时，您以与早期从蓝色到绿色相同的方式从绿色转换为蓝色。这样一来，绿色和蓝色环境都定期在现场，以前的版本（用于回滚）和下一个版本之间循环。

基本的想法是要有两个易于切换的环境可以切换，其中有很多方法可以改变细节。一个项目通过弹跳Web服务器而不是在路由器上工作来进行切换。另一个变体是使用相同的数据库，使Web和域层的蓝绿色开关。

数据库通常可能是一个挑战，尤其是当您需要更改schema以支持该软件的新版本时。诀窍是将schema更改的部署与应用程序升级分开。因此，首先数据库重构更改schema以支持应用程序的新版本和旧版本，部署该架构，检查所有内容都可以正常工作，以便您有回滚点，然后部署应用程序的新版本。 （当升级已卧床不起时，请删除对旧版本的数据库支持。）

优缺点

• 发布简单
• 硬件数量翻倍
• 快速回退

灰度发布/金丝雀发布

金丝雀发布，CanaryRelease，是一种降低在生产中引入新软件版本的风险的技术，方法是在将更改推广到整个基础架构并使其可供所有人使用之前，缓慢地将更改推广到一小部分用户。 首先将软件的新版本部署到基础架构的子集，没有用户被路由到该子集。

随着您对新版本的信心增强，您可以开始将其发布到基础架构中的更多服务器并将更多用户路由到它。推出新版本的一个好做法是使用PhoenixServers重新调整现有基础架构的用途，或者使用ImmutableServers配置新的基础架构并停用旧的基础架构。

Canary 版本是ParallelChange的一个应用程序，迁移阶段一直持续到所有用户都被路由到新版本。届时，您可以停用旧的基础设施。如果您发现新版本有任何问题，回滚策略只是将用户重新路由回旧版本，直到您解决了问题。

使用金丝雀版本的一个好处是能够在生产环境中对新版本进行容量测试，如果发现问题，可以采用安全的回滚策略。通过缓慢增加负载，您可以监控和捕获有关新版本如何影响生产环境的指标。这是创建完全独立的容量测试环境的另一种方法，因为该环境将尽可能地类似于生产环境。

在大型分布式场景中，不是使用路由器来决定哪些用户将被重定向到新版本，而是使用不同的分区策略也很常见。例如：如果您有地域分布的用户，您可以先将新版本推出到某个地区或特定位置；如果你有多个品牌，你可以先推广到一个品牌，等等。

Facebook 选择使用多个金丝雀的策略，第一个只对其内部员工可见，并且所有的FeatureToggles都打开，这样他们就可以检测新的问题特征早.

由于技术实现的相似性，Canary 版本可以用作实现 A/B 测试的一种方式。但是，最好避免将这两个问题混为一谈：虽然金丝雀版本是检测问题和回归的好方法，但 A/B 测试是一种使用变体实现来测试假设的方法。如果您使用 canary [2]监控业务指标以检测回归，那么也将其用于 A/B 测试可能会干扰结果。在更实际的情况下，收集足够的数据以证明 A/B 测试的统计意义可能需要几天时间，而您可能希望在几分钟或几小时内完成金丝雀部署。

使用金丝雀版本的一个缺点是您必须一次管理软件的多个版本。您甚至可以决定同时在生产中运行两个以上的版本，但是最好将并发版本的数量保持在最低限度。

另一个很难使用金丝雀版本的场景是当您分发安装在用户计算机或移动设备中的软件时。在这种情况下，您无法控制何时升级到新版本。如果分布式软件与后端通信，您可以使用ParallelChange来支持这两个版本并监控正在使用的客户端版本。一旦使用量下降到一定水平，您就可以收缩后端以仅支持新版本。

在进行金丝雀发布时，管理数据库更改也需要注意。同样，使用ParallelChange是一种缓解此问题的技术。它允许数据库在推出阶段支持应用程序的两个版本。

参考文献

1. BlueGreenDeployment – Martin Fowler
2. CanaryRelease – Danilo Sato
3. 灰度(金丝雀)发布、蓝绿部署、滚动发布 – 玄明Hanko

对称加密

对称密钥演算法（英语：Symmetric-key algorithm）又称为对称加密、私钥加密、共享密钥加密，是密码学中的一类加密演算法。这类演算法在加密和解密时使用相同的密钥，或是使用两个可以简单地相互推算的密钥。事实上，这组密钥成为在两个或多个成员间的共同秘密，以便维持专属的通讯联系[1]。要求双方取得相同的密钥是对称密钥加密的主要缺点之一。

常见的对称加密算法有AES、ChaCha20、3DES、Salsa20、DES、Blowfish、IDEA、RC5、RC6、Camellia。

对称加密的速度比非对称加密快很多，在很多场合都需要对称加密。

非对称加密

公开密钥密码学（英语：Public-key cryptography）也称非对称式密码学（英语：Asymmetric cryptography）是密码学的一种算法，它需要两个密钥，一个是公开密钥，另一个是私有密钥；公钥用作加密，私钥则用作解密。使用公钥把明文加密后所得的密文，只能用相对应的私钥才能解密并得到原本的明文，最初用来加密的公钥不能用作解密。由于加密和解密需要两个不同的密钥，故被称为非对称加密；不同于加密和解密都使用同一个密钥的对称加密。公钥可以公开，可任意向外发布；私钥不可以公开，必须由用户自行严格秘密保管，绝不透过任何途径向任何人提供，也不会透露给被信任的要通信的另一方。

基于公开密钥加密的特性，它还能提供数字签名的功能，使电子文件可以得到如同在纸本文件上亲笔签署的效果。

公开密钥基础建设透过信任数字证书认证机构的根证书、及其使用公开密钥加密作数字签名核发的公开密钥认证，形成信任链架构，已在TLS实现并在万维网的HTTP以HTTPS、在电邮的SMTP以SMTPS或STARTTLS引入。

在数学上，d(c(x))=x，使用典型的爱丽丝与鲍伯假设来解释：

1. 爱丽丝与鲍伯事先互不认识，也没有可靠安全的沟通渠道，但爱丽丝现在却要透过不安全的互联网向鲍伯发送信息
2. 爱丽丝撰写好原文，原文在未加密的状态下称之为明文 x
3. 鲍伯使用密码学安全伪随机数生成器产生一对密钥，其中一个作为公钥为 c，另一个作为私钥 d
4. 鲍伯可以用任何方法发送公钥 c 给爱丽丝，即使伊夫在中间窃听到 c 也没问题
5. 爱丽丝用公钥 c 把明文 x 进行加密，得到密文 c(x)
6. 爱丽丝可以用任何方法传输密文 c(x) 给鲍伯，即使伊夫在中间窃听到密文c(x) 也没问题
7. 鲍伯收到密文，用私钥 d 对密文进行解密 d(c(x))，得到爱丽丝撰写的明文x
8. 由于伊夫没有得到鲍伯的私钥 d，所以无法得知明文 x
9. 如果爱丽丝丢失了她自己撰写的原文 x，在没有得到鲍伯的私钥 d 的情况下，她的处境将等同伊夫，即无法透过鲍伯的公钥 c 和密文 c(x)重新得到原文 x

HTTPS

1. 客户端向服务端发送“hello”，包含自己支持的ssl/TLS的版本、以及支持的加密算法池
2. 服务端回复选择的加密算法c，并将公钥k和数字证书ca发给客户端
3. 客户端向证书中心请求校验证书ca，确保没有被中间人攻击，信任公钥k
4. 使用公钥k加密:自己生成的随机对称加密数d；发给服务端；服务端使用与公钥k对应的私钥k’进行解密；得到对称加密数d
5. 服务端使用对称加密数d，加密“Finish”报文，应答客户端；
6. 客户端使用对称加密数d，加密“Finish”报文，应答服务端；双方完成对称加密密钥的共享；

证书ca，如何防止中间人攻击

从证书申请流程可知，攻击者可以获得的是加密后的证书和读取证书的私钥；这样攻击者无法篡改证书； 因为只要证书被篡改，就无法重新被加密（加密的密钥只被CA中心持有）

客户端在收到证书后，解密阅读证书，查看信息与对端信息是否匹配，就可以判断对端是否是真正可信授权对象了。

参考文献

1. 公开密钥加密
2. 证书申请流程

E0603 undefined_all_variable

python中，当使用from module import *语句时，会导入这个module的所有非下划线开头的成语； 这样的操作存在本模块的命名空间被污染的问题。__all__的申明操作，可以在使用from module import *导入模块时，指定需要导入的成员。

test1.py and test2.py in the same package
-----------------
test1.py
__all__ = ['func1']

def func1():
    print("func1")


def func2():
    print("func2")


def _func3():
    print("func3")

----------------
test2.py
from test1 import *

func1()

# if test1.__all__ set
# NameError: name 'func2' is not defined
# func2()

# NameError: name 'func3' is not defined
# func3()  

E0604 invalid_all_object

在上面E0603的基础上__all__的申明对象，必须是string类型的。其它类型的对象不支持。

__all__ = (
  1, # [invalid-all-object]
  lambda: None, # [invalid-all-object]
  None, # [invalid-all-object]
)

会议的五个阶段

1. 准备
2. 收集数据
3. 产生见解
4. 确定改进项
5. 结素会议

准备

• 首先要设定一个安全的环境 申明会议的目的，不是追究任何人的责任的意思。并且明确会议中尽量避免讨论任何个人责任的问题
• 了解与会人的心态 收集大家的心态（Explorer：探索者，Shopper：推销者，Vacationer：度假者，Prisioner：囚犯）；不记名的投票，可以触发大家进行一次定位和思考
• 激发大家的发言欲望： 如果在一开始大家就可以不需要发言，只是听，那么很大概率大家在整个会议上都将保持沉默，没有什么想说的。所以一开始需要进行破冰： 轮流用一个词描述他对这个迭代的感受，因为不好形容准确，所以会让大家的头脑运转起来，进入回顾的思考中，并且获得了发言的机会。
• 把大家带到这个迭代的历史回忆中： 在进行收集数据前，让大家回忆一下这个迭代到底发生了什么。这个至关重要，不然暴露的问题很可能会变成天马行空的抱怨。 除了上面的用一个词来形容之外，还可以画心情曲线，把心情的好坏，按照时间维度进行曲线描述。每个人分享自己的心情曲线，有利于团队成员之间的相互了解，加强信任感。

收集数据

收集数据一般包含：

• 做的好的部分，要保持
• 做的不好的部分，要改进
• 创新想法部分，值得学习、尝试

这个环节可以通过贴纸卡片的方式，每个问题一张贴纸。除此之外，还有帆船回顾法。

产生见解

这个过程需要进行上面收集数据的归类，并且在这个过程中，大家讨论是否相同的描述，并进行合并。此时，对于做的好的部分需要给予认可并鼓励做的更好。 对于做的不好的地方，需要进行一次排序，选择top3。排序的过程可以是大家进行投票，每人2票。

确定改进项

确定待改进的重点之后，我们就需要讨论针对这些问题的改进方案。而确定改进方案，需要两步：

• 确定问题的根本原因
• 寻找解决方法

鱼骨图、5W法都可以帮助我们去寻找、分享问题的根本原因。 寻找根源时，可以分组分议题进行。可以限时讨论问题根源和推荐改进计划。这样可以节省时间，也能更好的调动每一个成员的积极性。

改进计划需要遵守SMART法则，在各组进行结论showcase时，需要提问大家，“这个AP是否可以执行？是否能够判断这个任务被完成。”

避免产生过多的改进项： 如果上面的过程产生过多的改进项，那么我们需要对改进项进行优先级排序，选择大家能力范围内可以完成的，不然没法落地。

结束会议

最后结束环节，可以是简单的对会议组织做个总结建议，提高会议组织能力。 另外，也可以每个人以一张感谢卡片，附上理由感谢一下团队中的一个人。然后请人宣读一下卡片内容，激励一个团队内的相互帮助和改善合作氛围。