左耳听风

如何让自己的技能变现

1. 千里之行，积于跬步
2. 关注有价值的东西
   • 关于市场需求
   • 关于技术趋势
3. 找到能体现价值的地方 。在一家高速发展的公司中，技术人员的价值可以达到最大化 。
4. 动手能力很重要
5. 关注技术付费点
   • 能帮别人“挣钱”的地方
   • 能帮别人“省钱”的地方
6. 提升自己的能力和经历
7. 找到有价值的信息源
8. 输出观点和价值观
9. 朋友圈很重要
   • 这些人都比较有想法、有观点，经验也比较丰富；
   • 这些人涉猎的面比较广；
   • 这些人都有或多或少的成功；
   • 这些人都是喜欢折腾喜欢搞事的人；
   • 这些人都对现状有些不满，并想做一些改变；
   • 这些人都有一定的影响力。

从三次工业革命论证技术领导力

第一次工业革命：蒸汽机，第二次：电力，第三次：计算机。近代这几百年的人类发展史，从蒸汽机时代，到电力时代，再到信息时代，我们可以看到这样的一些要素：关键技术、自动化、解放生产力。

因此，我们可以看到的技术领导力是：

• 尊重技术，追求核心基础技术。
• 追逐自动化的高效率的工具和技术，同时避免无效率的组织架构和管理。
• 解放生产力，追逐人效的提高。
• 开发抽象和高质量的可以重用的技术组件。
• 坚持高于社会主流的技术标准和要求。

如何拥有技术领导力？

1. 你要吃透基础技术。基础技术是各种上层技术共同的基础。
2. 提高学习能力。所谓学习能力，就是能够很快地学习新技术，又能在关键技术上深入的能力。
3. 坚持做正确的事。
4. 高标准要求自己。只有不断地提高标准 ，你才可能越走越高，所以，要以高标准要求自己，不断地反思、总结和审视自己，才能够提升自己 。

拥有技术领导力程序员特性

• 能够发现问题
• 能够提供解决问题的思路和方案，并能比较这些方案的优缺点
• 能够做出正确的技术决定
• 能够用更优雅，更简单，更容易的方式来解决问题
• 能够提高代码或软件的扩展性、重用性和可维护性
• 能够用正确的方式管理团队
  1. 让正确的人做正确的事，并发挥每个人的潜力
  2. 不断地提高自身和团队的标准，从而提高团队的生产力和人效
• 创新能力

如何判断一种技术的发展前景？

1. 有没有一个比较好的社区
2. 有没有一个工业化的标准
3. 有没有一个或多个杀手级应用
4. 学习难度是否低，上手是否快
5. 有没有一个不错的提高开发效率的开发框架
6. 是否有一个或多个巨型的技术公司作为后盾
7. 有没有解决软件开发中的痛点

技术Leader的一些思考

• 信任
• 开放的心态
• 以身作则
• 保持热情和冲劲
• 能够抓住重点，看透事物的本质
• 眼光
• 心胸

Never Say No

1. 当你面对做不到的需求时，给出另一个你可以做到的方案，而不是把对方的方案直接回绝掉 。
2. 当你面对过于复杂的需求时，我不说我不能完全满足你，但我说我可以部分满足你 。

我不能说不，但是我要有条件地说是。

规划自己的时间

• 定义好优先级
• 最短作业优先
• 想清楚再做
• 关注长期利益规划

你要学会规划自己的行动计划，不是短期的，而是一个中长期的。我个人建议是按季度来规划，这个季度做什么，达到什么目标，一年往前走四步，而不是只考虑眼下。

隔离设计

于系统的分离有两种方式，一种是以服务的种类来做分离，一种是以用户来做分离。

• 服务分离

我们将系统分成了用户、商品、社区三个板块。这三个块分别使用不同的域名、服务器和数据库，做到从接入层到应用层再到数据层三层完全隔离。

1. 如果我们需要同时获得多个板块的数据，那么就需要调用多个服务，这会降低性能。
2. 如果有大数据平台，就需要把这些数据都抽取到一个数据仓库中进行计算，这也增加了数据合并的复杂度。
3. 如果我们的业务逻辑或是业务流程需要跨板块的话，那么一个板块的故障也会导致整个流程走不下去，同样会导致整体业务故障。
4. 如果需要有跨板块的交互也会变得有点复杂。对此我们需要一个类似于Pub/Sub的高可用、且可以持久化的消息订阅通知中间件来打通各个板块的数据和信息交换。
5. 最后还会有在多个板块中分布式事务的问题。对此，我们需要“二阶段提交”这样的方案。也就是说，先做一个plan的API调用，然后各个子系统reserve住相应的资源，如果成功，则Commit；如果有一个失败，则整体Cancel。

• 用户分离（多租户模式）

1. 完全独立的设计。每个租户有自己完全独立的服务和数据。
2. 独立的数据分区，共享的服务。多租户的服务是共享的，但数据是分开隔离的。
3. 共享的服务，共享的数据分区。每个租户的数据和服务都是共享的。

隔离设计的重点

• 把握好隔离业务的大小和粒度
• 隔离模式需要配置一些高可用、重试、异步、消息中间件，流控、熔断等设计模式的方式配套使用。
• 自动化运维和监控系统

异步通讯设计

隔离设计通常都需要对系统做解耦设计，业务拆分完后面对最主要的问题就是通讯问题！

• 同步通讯

1. 影响吞吐量
2. 消耗系统资源
3. 只能一对一
4. 有多米诺骨牌效应（整个通讯链受最慢的一个服务影响）

• 异步通讯

1. 请求响应式，如：支付异步回调
2. 订阅方式
3. Broker方式

• 事件驱动架构（EDA – Event Driven Architecture）

事件驱动最好是使用Broker方式，服务间通过交换消息来完成交流和整个流程的驱动。

事件驱动减少了服务间依赖关系、增加吞吐量、方便服务的开发运维、增加一些Adapter（如日志、认证、版本、限流、降级、熔断等）。

事件驱动导致业务流程不再那么明显和好管理，整个架构变得比较复杂。事务处理变得复杂。需要使用两阶段提交来做强一致性，或是退缩到最终一致性。

消息传递中，可能有的业务逻辑会有像TCP协议那样的send和ACK机制。需要处理方有幂等的处理，即同一件消息无论收到多少次都只处理一次。

ACID 和 BASE

ACID(酸)强一致性

• 原子性(Atomicity)： 整个事务中的所有操作，要么全部完成，要么全部失败，不可能停滞在中间某个环节。
• 一致性(Consistency)： 在事务开始之前和事务结束以后，数据库的完整性约束没有被破坏。
• 隔离性(Isolation)： 两个事务的执行是互不干扰的，一个事务不可能看到其他事务运行时中间某一时刻的数据。两个事务不会发生交互。
• 持久性(Durability)： 在事务完成以后，该事务对数据库所做的更改便持久地保存在数据库之中，并不会被回滚。

BASE(碱)最终一致性

• Basic Availability： 基本可用。这意味着，系统可以出现暂时不可用的状态，而后面会快速恢复。
• Soft-state： 软状态。也就是说，为了提高性能，我们可以让服务暂时保存一些状态或数据，这些状态和数据不是强一致性的。
• Eventual Consistency： 最终一致性，系统在一个短暂的时间段内是不一致的，但最终整个系统看到的数据是一致的。

我们都很熟悉CAP理论——在分布式的服务架构中，一致性（Consistency）、可用性（Availability）、分区容忍性（Partition Tolerance），在现实中不能都满足，最多只能满足其中两个。

有趣的是，ACID的意思是酸，而BASE却是碱的意思，因此这是一个对立的东西。其实，从本质上来讲，酸（ACID）强调的是一致性（CAP中的C），而碱（BASE）强调的是可用性（CAP中的A）。

限流、降级、熔断

保护系统不会在过载的情况下出现问题，我们就需要限流。

• 限流的策略

1. 拒绝服务
2. 服务降级
3. 特权请求
4. 延时处理
5. 弹性伸缩

• 限流的实现方式

1. 计数器方式
2. 队列算法
3. 漏斗算法
4. 令牌桶算法
5. 滑动窗口限流

从理论上来说，令牌桶的算法和漏斗算法不一样的是，漏斗算法中，处理请求是以一个常量和恒定的速度处理的，而令牌桶算法则是在流量小的时候“攒钱”，流量大的时候，可以快速处理。

上面的算法有个不好的地方，就是需要设置一个确定的限流值。然而，在很多时候，我们却并不知道这个限流值，或是很难给出一个合适的值。

我们想使用一种动态限流的方式。这种方式，不再设定一个特定的流控值，而是能够动态地感知系统的压力来自动化地限流。即：滑动窗口限流

一般来说，我们的降级需要牺牲掉的东西有：

1. 降低一致性 。从强一致性变成最终一致性。
2. 停止次要功能 。停止访问不重要的功能，从而释放出更多的资源。
3. 简化功能 。把一些功能简化掉，比如，简化业务流程，或是不再返回全量数据，只返回部分数据。

一个网关在限流时，在协议头中加入了一个限流程度的参数，让后端服务能知道限流在发生中。当限流程度达到某个值时，或是限流时间超过某个值时，就自动开始降级，直到限流好转。

熔断设计

在我们的分布式系统设计中重试机制，如果错误太多，或是在短时间内得不到修复，那么我们重试也没有意义了，此时应该开启我们的熔断操作，尤其是后端太忙的时候，使用熔断设计可以保护后端不会过载。

• 闭合（Closed）状态
• 断开(Open)状态
• 半开（Half-Open）状态

熔断设计中三个状态分别对应于正常、故障和故障后检测故障是否已被修复的场景。

弹力设计总图

分布式锁

# SET NX 命令只会在 key 不存在的时候给 key 赋值，PX 命令通知Redis保存这个key 30000ms
SET key value NX PX 30000

Redis的分布式锁使用原子性操作加锁，用lua脚本解锁(防止误删其他人的锁)。

网关模式

网关模式设计

• 请求路由
• 服务注册
• 负载均衡
• 弹力设计：异步、重试、幂等、流控、熔断、监视
• 安全方面：SSL加密及证书管理、Session验证、授权、数据校验，以及对请求源进行恶意攻击的防范。

部署升级策略

• 停机部署（Big Bang / Recreate）： 把现有版本的服务停机，然后部署新的版本。
• 蓝绿部署（Blue/Green /Stage）：部署好新版本后，把流量从老服务那边切过来。
• 滚动部署（Rolling Update / Ramped）： 一点一点地升级现有的服务。
• 灰度部署（Canary）：把一部分用户切到新版本上来，然后看一下有没有问题。如果没有问题就继续扩大升级，直到全部升级完成。灰度部署也可以将一些新的版本先部署到一些用户上，如果没有问题，扩大部署，直到全部用户。一般的策略是，从内部用户开始，然后是一般用户，最后是大客户。
• AB测试（A/B Testing）：同时上线两个版本，然后做相关的比较。

高效学习

• 被动学习： 如听讲、阅读、视听、演示，学习内容的平均留存率为5%、10%、20%和30%。
• 主动学习： 如通过讨论、实践、教授给他人，会将原来被动学习的内容留存率从5%提升到50%、75%和90%。

学习不是努力读更多的书，盲目追求阅读的速度和数量，这会让人产生低层次的勤奋和成长的感觉，这只是在使蛮力。要思辨，要践行，要总结和归纳，否则，你只是在机械地重复某件事，而不会有质的成长的。

深度学习

• 知识采集，高质量的信息源和第一手的知识。
• 知识缝合，把知识连成地图，将自己的理解反述出来 。
• 技能转换，不断地反思和思辨，与不同年龄段的人讨论，举一反三、实践和练习 ，以及传授教导。

形成知识地图，融会贯通！

Talk is cheap, show me the code

Talk是人对人说的话，而Code也不仅仅只是人对机器说的话，也更是另外一种人对人说的话（因为Code需要易读和易维护，就需要让人读懂）,其实，Talk并不cheap，而Code才是其中比较cheap的。

有效的沟通是事业成功的必要条件

通是指运用语言、文字或一些特定的非语言行为（面部表情、肢体动作等），把自己的想法、要求、信息等内容传递给对方。

高效沟通沟通方式及技巧

• 尊重
• 倾听
• 情绪控制
• 引起对方的兴趣：沟通之前，你要想方设法引起对方的兴趣，这里面你要思考对方最关注什么，你可以帮到他什么。
• 直达主题，强化观点：要做到这一点，你需要过滤信息，简明扼要地表达。也就是说你要明确自己的沟通目的，然后围绕目的不断迭代自己的表达内容。同时，你可以用换位思考法来进一步确保自己的表达能够准确无误传递给对方。
• 基于数据和事实：沟通的时候，你应该尽量少用“可能”、“也许”之类不确定的话术，转而使用数据和实例等确定性的语言来夯实你的观点，当然，这中间你要学会如何积累“实例”。 这三样东西不仅可以帮你解决绝大多数问题，而且可以把你的沟通变得简单粗暴、直接有效。

---

学习 左耳朵耗子专栏《左耳听风》的一些摘抄和思考