软件杂谈《六》

　　高可用性（HA）

　　每个人都有两个肾。为了apple watch卖掉一个肾，另一个还能保证人体的正常工作。当然，人的两个肾是Active-Active工作模式，内部的肾元（micro service）是 N(active)+M(backup) clustering 工作的（看看人家这service的做的），少了一个，performance会一点点有折扣，但可以忽略不计。

　　大部分软件系统里的各种服务也需要高可用性：除非完全无状态的服务，且服务重启时间在ms级。服务的高可用性和路由是息息相关的：高可用性往往意味着同一服务的冗余，同时也意味着负载分担。好的路由系统（如consul）能够对路由至同一服务的数据在多个冗余服务间进行负载分担，同时在检测出某个失效服务后，将数据路只由至正常运作的服务。

　　高可用性还意味着非关键服务，即便不可恢复，也只会导致系统降级，而不会让整个系统无法访问。就像壁虎的尾巴断了不妨碍壁虎逃命，人摔伤了手臂还能吃饭一样，一个软件系统里统计模块的异常不该让用户无法访问他的个人页面。

　　安保（security）

　　安保服务分为主动安全和被动安全。authentication/authorization + TLS + 敏感信息加密 + 最小化输入输出接口可以算是主动安全，防火墙等安防系统则是被动安全。

　　继续拿你的肾来比拟 —— 肾脏起码有两大安全系统：

1. 输入安全。肾器的厚厚的器官膜，保护器官的输入输出安全 —— 主要的输入输出只能是肾动脉，肾静脉和输尿管。

2. 环境安全。肾器里有大量脂肪填充，避免在撞击时对核心功能的损伤。

　　除此之外，人体还提供了包括免疫系统，皮肤，骨骼，空腔等一系列安全系统，从各个维度最大程度保护一个器官的正常运作。如果我们仔细研究生物，就会发现，安保是个一揽子解决方案：小到细胞，大到整个人体，都有各自的安全措施。一个软件系统也需如此考虑系统中各个层次的安全。

　　透支保护（overdraft protection）

　　任何系统，任何服务都是有服务能力的 —— 当这能力被透支时，需要一定的应急计划。如果使用拥有auto scaling的云服务（如AWS），动态扩容是最好的解决之道，但受限于所用的解决方案，它并非万灵药，AWS的auto scaling依赖于load balancer，如Amazon自有的ELB，或者第三方的HAProxy，但ELB对某些业务，如websocket，支持不佳；而第三方的load balancer，则需要考虑部署，与Amazon的auto scaling结合（需要写点代码），避免单点故障，保证自身的capacity等一堆头疼事。

　　在无法auto scaling的场景最通用的做法是back pressure，把压力反馈到源头。就好像你不断熬夜，最后大脑受不了，逼着你睡觉一样。还有一种做法是服务降级，停掉非核心的service/micro-service，如analytical service，ad service，保证核心功能正常。

　　把设计的成果讲给别人听

　　完成了分解和组合，也严肃对待了诸多与业务没有直接关系，但又不得不做的必要功能后，接下来就是要把设计在白板上画下来，讲给任何一个利益相关者听。听他们的反馈。设计不是一个闭门造车的过程，全程都需要和各种利益相关者交流。然而，很多人都忽视了设计定型后，继续和外界交流的必要性。很多人会认为：我的软件架构，设计结果和工程有关，为何要讲给工程师以外的人听？他们懂么？

　　其实pitch本身就是自我学习和自我修正的一部分。当着一个人或者几个人的面，在白板上画下脑海中的设计的那一刻，你就会有直觉哪个地方似乎有问题，这是很奇特的一种体验：你自己画给自己看并不会产生这种直觉。这大概是面对公众的焦灼产生的肾上腺素的效果。:)

　　此外，从听者的表情，或者他们提的听起来很傻很天真的问题，你会进一步知道哪些地方你以为你搞通了，其实自己是一知半解。太简单，太基础的问题，我们take it for granted，不屑去问自己，非要有人点出，自己才发现：啊，原来这里我也不懂哈。这就是破解 "you don’t know what you don’t know" 之法。

　　记得看过一个video，主讲人大谈企业文化，有个哥们傻乎乎发问：so what it culture literally? 主讲人愣了一下，拖拖拉拉讲了一堆自己都不能让自己信服的废话。估计回头他就去查韦氏词典了。

　　最后，总有人在某些领域的知识更丰富一些，他们会告诉你你一些你知道自己不懂的事情。填补了 "you know that you don’t know" 的空缺。

　　高可用性（HA）

　　每个人都有两个肾。为了apple watch卖掉一个肾，另一个还能保证人体的正常工作。当然，人的两个肾是Active-Active工作模式，内部的肾元（micro service）是 N(active)+M(backup) clustering 工作的（看看人家这service的做的），少了一个，performance会一点点有折扣，但可以忽略不计。

　　大部分软件系统里的各种服务也需要高可用性：除非完全无状态的服务，且服务重启时间在ms级。服务的高可用性和路由是息息相关的：高可用性往往意味着同一服务的冗余，同时也意味着负载分担。好的路由系统（如consul）能够对路由至同一服务的数据在多个冗余服务间进行负载分担，同时在检测出某个失效服务后，将数据路只由至正常运作的服务。

　　高可用性还意味着非关键服务，即便不可恢复，也只会导致系统降级，而不会让整个系统无法访问。就像壁虎的尾巴断了不妨碍壁虎逃命，人摔伤了手臂还能吃饭一样，一个软件系统里统计模块的异常不该让用户无法访问他的个人页面。

　　安保（security）

　　安保服务分为主动安全和被动安全。authentication/authorization + TLS + 敏感信息加密 + 最小化输入输出接口可以算是主动安全，防火墙等安防系统则是被动安全。

　　继续拿你的肾来比拟 —— 肾脏起码有两大安全系统：

1. 输入安全。肾器的厚厚的器官膜，保护器官的输入输出安全 —— 主要的输入输出只能是肾动脉，肾静脉和输尿管。

2. 环境安全。肾器里有大量脂肪填充，避免在撞击时对核心功能的损伤。

　　除此之外，人体还提供了包括免疫系统，皮肤，骨骼，空腔等一系列安全系统，从各个维度最大程度保护一个器官的正常运作。如果我们仔细研究生物，就会发现，安保是个一揽子解决方案：小到细胞，大到整个人体，都有各自的安全措施。一个软件系统也需如此考虑系统中各个层次的安全。

　　透支保护（overdraft protection）

　　任何系统，任何服务都是有服务能力的 —— 当这能力被透支时，需要一定的应急计划。如果使用拥有auto scaling的云服务（如AWS），动态扩容是最好的解决之道，但受限于所用的解决方案，它并非万灵药，AWS的auto scaling依赖于load balancer，如Amazon自有的ELB，或者第三方的HAProxy，但ELB对某些业务，如websocket，支持不佳；而第三方的load balancer，则需要考虑部署，与Amazon的auto scaling结合（需要写点代码），避免单点故障，保证自身的capacity等一堆头疼事。

　　在无法auto scaling的场景最通用的做法是back pressure，把压力反馈到源头。就好像你不断熬夜，最后大脑受不了，逼着你睡觉一样。还有一种做法是服务降级，停掉非核心的service/micro-service，如analytical service，ad service，保证核心功能正常。

　　把设计的成果讲给别人听

　　完成了分解和组合，也严肃对待了诸多与业务没有直接关系，但又不得不做的必要功能后，接下来就是要把设计在白板上画下来，讲给任何一个利益相关者听。听他们的反馈。设计不是一个闭门造车的过程，全程都需要和各种利益相关者交流。然而，很多人都忽视了设计定型后，继续和外界交流的必要性。很多人会认为：我的软件架构，设计结果和工程有关，为何要讲给工程师以外的人听？他们懂么？

　　其实pitch本身就是自我学习和自我修正的一部分。当着一个人或者几个人的面，在白板上画下脑海中的设计的那一刻，你就会有直觉哪个地方似乎有问题，这是很奇特的一种体验：你自己画给自己看并不会产生这种直觉。这大概是面对公众的焦灼产生的肾上腺素的效果。:)

　　此外，从听者的表情，或者他们提的听起来很傻很天真的问题，你会进一步知道哪些地方你以为你搞通了，其实自己是一知半解。太简单，太基础的问题，我们take it for granted，不屑去问自己，非要有人点出，自己才发现：啊，原来这里我也不懂哈。这就是破解 "you don’t know what you don’t know" 之法。

　　记得看过一个video，主讲人大谈企业文化，有个哥们傻乎乎发问：so what it culture literally? 主讲人愣了一下，拖拖拉拉讲了一堆自己都不能让自己信服的废话。估计回头他就去查韦氏词典了。

　　最后，总有人在某些领域的知识更丰富一些，他们会告诉你你一些你知道自己不懂的事情。填补了 "you know that you don’t know" 的空缺。

　　设计时的tradeoff

　　Rich hickey（clojure作者）在某个演讲中说：

everyone says design is about tradeoffs, but you need to enumerate at least two or more possible solutions, and the attributes and deficits of each, in order to make tradeoff.

　　所以，下回再腆着脸说：偶做了些tradeoff，先确保自己做足了功课再说。

　　设计的改变不可避免

　　设计不是一锤子买卖，改变不可避免。我之前的一个老板，喜欢把 change is your friend 挂在口头。软件开发的整个生命周期，变更是家常便饭，以至于变更管理都生出一门学问。软件的设计期更是如此。人总会犯错，设计总有缺陷，需求总会变化，老板总会指手画脚，PM总有一天会亮出獠牙，不再是贴心大哥，或者美萌小妹。。。所以，据理力争，然后接受必要的改变即可。连凯恩斯他老人家都说：

 

　What do you do, sir?