分布式锁

分布式,

转载请务必注明原创地址为：http://www.54tianzhisheng.cn/2018/04/24/Distributed_lock/

什么是锁？

  • 在单进程的系统中，当存在多个线程可以同时改变某个变量（可变共享变量）时，就需要对变量或代码块做同步，使其在修改这种变量时能够线性执行消除并发修改变量。
  • 而同步的本质是通过锁来实现的。为了实现多个线程在一个时刻同一个代码块只能有一个线程可执行，那么需要在某个地方做个标记，这个标记必须每个线程都能看到，当标记不存在时可以设置该标记，其余后续线程发现已经有标记了则等待拥有标记的线程结束同步代码块取消标记后再去尝试设置标记。这个标记可以理解为锁。
  • 不同地方实现锁的方式也不一样，只要能满足所有线程都能看得到标记即可。如 Java 中 synchronize 是在对象头设置标记，Lock 接口的实现类基本上都只是某一个 volitile 修饰的 int 型变量其保证每个线程都能拥有对该 int 的可见性和原子修改，linux 内核中也是利用互斥量或信号量等内存数据做标记。
  • 除了利用内存数据做锁其实任何互斥的都能做锁（只考虑互斥情况），如流水表中流水号与时间结合做幂等校验可以看作是一个不会释放的锁，或者使用某个文件是否存在作为锁等。只需要满足在对标记进行修改能保证原子性和内存可见性即可。

什么是分布式？

分布式的 CAP 理论告诉我们:

任何一个分布式系统都无法同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance），最多只能同时满足两项。

目前很多大型网站及应用都是分布式部署的，分布式场景中的数据一致性问题一直是一个比较重要的话题。基于 CAP理论，很多系统在设计之初就要对这三者做出取舍。在互联网领域的绝大多数的场景中，都需要牺牲强一致性来换取系统的高可用性，系统往往只需要保证最终一致性。

分布式场景

此处主要指集群模式下，多个相同服务同时开启.

在许多的场景中，我们为了保证数据的最终一致性，需要很多的技术方案来支持，比如分布式事务、分布式锁等。很多时候我们需要保证一个方法在同一时间内只能被同一个线程执行。在单机环境中，通过 Java 提供的并发 API 我们可以解决，但是在分布式环境下，就没有那么简单啦。

  • 分布式与单机情况下最大的不同在于其不是多线程而是多进程。
  • 多线程由于可以共享堆内存，因此可以简单的采取内存作为标记存储位置。而进程之间甚至可能都不在同一台物理机上，因此需要将标记存储在一个所有进程都能看到的地方。

什么是分布式锁？

  • 当在分布式模型下，数据只有一份（或有限制），此时需要利用锁的技术控制某一时刻修改数据的进程数。
  • 与单机模式下的锁不仅需要保证进程可见，还需要考虑进程与锁之间的网络问题。（我觉得分布式情况下之所以问题变得复杂，主要就是需要考虑到网络的延时和不可靠。。。一个大坑）
  • 分布式锁还是可以将标记存在内存，只是该内存不是某个进程分配的内存而是公共内存如 Redis、Memcache。至于利用数据库、文件等做锁与单机的实现是一样的，只要保证标记能互斥就行。

我们需要怎样的分布式锁？

  • 可以保证在分布式部署的应用集群中，同一个方法在同一时间只能被一台机器上的一个线程执行。
  • 这把锁要是一把可重入锁（避免死锁）
  • 这把锁最好是一把阻塞锁（根据业务需求考虑要不要这条）
  • 这把锁最好是一把公平锁（根据业务需求考虑要不要这条）
  • 有高可用的获取锁和释放锁功能
  • 获取锁和释放锁的性能要好

基于数据库做分布式锁

基于乐观锁

基于表主键唯一做分布式锁

利用主键唯一的特性，如果有多个请求同时提交到数据库的话，数据库会保证只有一个操作可以成功，那么我们就可以认为操作成功的那个线程获得了该方法的锁，当方法执行完毕之后，想要释放锁的话，删除这条数据库记录即可。

上面这种简单的实现有以下几个问题：

  • 这把锁强依赖数据库的可用性，数据库是一个单点，一旦数据库挂掉，会导致业务系统不可用。
  • 这把锁没有失效时间，一旦解锁操作失败，就会导致锁记录一直在数据库中，其他线程无法再获得到锁。
  • 这把锁只能是非阻塞的，因为数据的 insert 操作，一旦插入失败就会直接报错。没有获得锁的线程并不会进入排队队列，要想再次获得锁就要再次触发获得锁操作。
  • 这把锁是非重入的，同一个线程在没有释放锁之前无法再次获得该锁。因为数据中数据已经存在了。
  • 这把锁是非公平锁，所有等待锁的线程凭运气去争夺锁。
  • 在 MySQL 数据库中采用主键冲突防重，在大并发情况下有可能会造成锁表现象。

当然，我们也可以有其他方式解决上面的问题。

  • 数据库是单点？搞两个数据库，数据之前双向同步，一旦挂掉快速切换到备库上。
  • 没有失效时间？只要做一个定时任务，每隔一定时间把数据库中的超时数据清理一遍。
  • 非阻塞的？搞一个 while 循环，直到 insert 成功再返回成功。
  • 非重入的？在数据库表中加个字段，记录当前获得锁的机器的主机信息和线程信息，那么下次再获取锁的时候先查询数据库，如果当前机器的主机信息和线程信息在数据库可以查到的话，直接把锁分配给他就可以了。
  • 非公平的？再建一张中间表，将等待锁的线程全记录下来，并根据创建时间排序，只有最先创建的允许获取锁。
  • 比较好的办法是在程序中生产主键进行防重。

基于表字段版本号做分布式锁

这个策略源于 mysql 的 mvcc 机制，使用这个策略其实本身没有什么问题，唯一的问题就是对数据表侵入较大，我们要为每个表设计一个版本号字段，然后写一条判断 sql 每次进行判断，增加了数据库操作的次数，在高并发的要求下，对数据库连接的开销也是无法忍受的。

基于悲观锁

基于数据库排他锁做分布式锁

在查询语句后面增加for update，数据库会在查询过程中给数据库表增加排他锁 (注意： InnoDB 引擎在加锁的时候，只有通过索引进行检索的时候才会使用行级锁，否则会使用表级锁。这里我们希望使用行级锁，就要给要执行的方法字段名添加索引，值得注意的是，这个索引一定要创建成唯一索引，否则会出现多个重载方法之间无法同时被访问的问题。重载方法的话建议把参数类型也加上。)。当某条记录被加上排他锁之后，其他线程无法再在该行记录上增加排他锁。

我们可以认为获得排他锁的线程即可获得分布式锁，当获取到锁之后，可以执行方法的业务逻辑，执行完方法之后，通过connection.commit()操作来释放锁。

这种方法可以有效的解决上面提到的无法释放锁和阻塞锁的问题。

  • 阻塞锁？ for update语句会在执行成功后立即返回，在执行失败时一直处于阻塞状态，直到成功。
  • 锁定之后服务宕机，无法释放？使用这种方式，服务宕机之后数据库会自己把锁释放掉。

但是还是无法直接解决数据库单点和可重入问题。

这里还可能存在另外一个问题，虽然我们对方法字段名使用了唯一索引，并且显示使用 for update 来使用行级锁。但是，MySQL 会对查询进行优化，即便在条件中使用了索引字段，但是否使用索引来检索数据是由 MySQL 通过判断不同执行计划的代价来决定的，如果 MySQL 认为全表扫效率更高，比如对一些很小的表，它就不会使用索引，这种情况下 InnoDB 将使用表锁，而不是行锁。如果发生这种情况就悲剧了。。。

还有一个问题，就是我们要使用排他锁来进行分布式锁的 lock，那么一个排他锁长时间不提交，就会占用数据库连接。一旦类似的连接变得多了，就可能把数据库连接池撑爆。

优缺点

优点：简单，易于理解

缺点：会有各种各样的问题（操作数据库需要一定的开销，使用数据库的行级锁并不一定靠谱，性能不靠谱）

基于 Redis 做分布式锁

基于 redis 的 setnx()、expire() 方法做分布式锁

setnx()

setnx 的含义就是 SET if Not Exists，其主要有两个参数 setnx(key, value)。该方法是原子的，如果 key 不存在，则设置当前 key 成功，返回 1；如果当前 key 已经存在，则设置当前 key 失败，返回 0。

expire()

expire 设置过期时间，要注意的是 setnx 命令不能设置 key 的超时时间，只能通过 expire() 来对 key 设置。

使用步骤

1、setnx(lockkey, 1) 如果返回 0，则说明占位失败；如果返回 1，则说明占位成功

2、expire() 命令对 lockkey 设置超时时间，为的是避免死锁问题。

3、执行完业务代码后，可以通过 delete 命令删除 key。

这个方案其实是可以解决日常工作中的需求的，但从技术方案的探讨上来说，可能还有一些可以完善的地方。比如，如果在第一步 setnx 执行成功后，在 expire() 命令执行成功前，发生了宕机的现象，那么就依然会出现死锁的问题，所以如果要对其进行完善的话，可以使用 redis 的 setnx()、get() 和 getset() 方法来实现分布式锁。

基于 redis 的 setnx()、get()、getset()方法做分布式锁

这个方案的背景主要是在 setnx() 和 expire() 的方案上针对可能存在的死锁问题，做了一些优化。

getset()

这个命令主要有两个参数 getset(key，newValue)。该方法是原子的，对 key 设置 newValue 这个值，并且返回 key 原来的旧值。假设 key 原来是不存在的，那么多次执行这个命令，会出现下边的效果：

  1. getset(key, “value1”) 返回 null 此时 key 的值会被设置为 value1
  2. getset(key, “value2”) 返回 value1 此时 key 的值会被设置为 value2
  3. 依次类推！
使用步骤
  1. setnx(lockkey, 当前时间+过期超时时间)，如果返回 1，则获取锁成功；如果返回 0 则没有获取到锁，转向 2。
  2. get(lockkey) 获取值 oldExpireTime ，并将这个 value 值与当前的系统时间进行比较，如果小于当前系统时间，则认为这个锁已经超时，可以允许别的请求重新获取，转向 3。
  3. 计算 newExpireTime = 当前时间+过期超时时间，然后 getset(lockkey, newExpireTime) 会返回当前 lockkey 的值currentExpireTime。
  4. 判断 currentExpireTime 与 oldExpireTime 是否相等，如果相等，说明当前 getset 设置成功，获取到了锁。如果不相等，说明这个锁又被别的请求获取走了，那么当前请求可以直接返回失败，或者继续重试。
  5. 在获取到锁之后，当前线程可以开始自己的业务处理，当处理完毕后，比较自己的处理时间和对于锁设置的超时时间，如果小于锁设置的超时时间，则直接执行 delete 释放锁；如果大于锁设置的超时时间，则不需要再锁进行处理。

基于 Redlock 做分布式锁

Redlock 是 Redis 的作者 antirez 给出的集群模式的 Redis 分布式锁，它基于 N 个完全独立的 Redis 节点（通常情况下 N 可以设置成 5）。

算法的步骤如下：

  • 1、客户端获取当前时间，以毫秒为单位。
  • 2、客户端尝试获取 N 个节点的锁，（每个节点获取锁的方式和前面说的缓存锁一样），N 个节点以相同的 key 和 value 获取锁。客户端需要设置接口访问超时，接口超时时间需要远远小于锁超时时间，比如锁自动释放的时间是 10s，那么接口超时大概设置 5-50ms。这样可以在有 redis 节点宕机后，访问该节点时能尽快超时，而减小锁的正常使用。
  • 3、客户端计算在获得锁的时候花费了多少时间，方法是用当前时间减去在步骤一获取的时间，只有客户端获得了超过 3 个节点的锁，而且获取锁的时间小于锁的超时时间，客户端才获得了分布式锁。
  • 4、客户端获取的锁的时间为设置的锁超时时间减去步骤三计算出的获取锁花费时间。
  • 5、如果客户端获取锁失败了，客户端会依次删除所有的锁。
    使用 Redlock 算法，可以保证在挂掉最多 2 个节点的时候，分布式锁服务仍然能工作，这相比之前的数据库锁和缓存锁大大提高了可用性，由于 redis 的高效性能，分布式缓存锁性能并不比数据库锁差。

但是，有一位分布式的专家写了一篇文章《How to do distributed locking》，质疑 Redlock 的正确性。

https://mp.weixin.qq.com/s/1bPLk_VZhZ0QYNZS8LkviA

https://blog.csdn.net/jek123456/article/details/72954106

优缺点

优点：

性能高

缺点：

失效时间设置多长时间为好？如何设置的失效时间太短，方法没等执行完，锁就自动释放了，那么就会产生并发问题。如果设置的时间太长，其他获取锁的线程就可能要平白的多等一段时间。

基于 redisson 做分布式锁

redisson 是 redis 官方的分布式锁组件。GitHub 地址：https://github.com/redisson/redisson

上面的这个问题 ——> 失效时间设置多长时间为好？这个问题在 redisson 的做法是：每获得一个锁时，只设置一个很短的超时时间，同时起一个线程在每次快要到超时时间时去刷新锁的超时时间。在释放锁的同时结束这个线程。

基于 ZooKeeper 做分布式锁

zookeeper 锁相关基础知识

  • zk 一般由多个节点构成（单数），采用 zab 一致性协议。因此可以将 zk 看成一个单点结构，对其修改数据其内部自动将所有节点数据进行修改而后才提供查询服务。
  • zk 的数据以目录树的形式，每个目录称为 znode， znode 中可存储数据（一般不超过 1M），还可以在其中增加子节点。
  • 子节点有三种类型。序列化节点，每在该节点下增加一个节点自动给该节点的名称上自增。临时节点，一旦创建这个 znode 的客户端与服务器失去联系，这个 znode 也将自动删除。最后就是普通节点。
  • Watch 机制，client 可以监控每个节点的变化，当产生变化会给 client 产生一个事件。

zk 基本锁

  • 原理：利用临时节点与 watch 机制。每个锁占用一个普通节点 /lock，当需要获取锁时在 /lock 目录下创建一个临时节点，创建成功则表示获取锁成功，失败则 watch/lock 节点，有删除操作后再去争锁。临时节点好处在于当进程挂掉后能自动上锁的节点自动删除即取消锁。
  • 缺点：所有取锁失败的进程都监听父节点，很容易发生羊群效应，即当释放锁后所有等待进程一起来创建节点，并发量很大。

zk 锁优化

  • 原理：上锁改为创建临时有序节点，每个上锁的节点均能创建节点成功，只是其序号不同。只有序号最小的可以拥有锁，如果这个节点序号不是最小的则 watch 序号比本身小的前一个节点 (公平锁)。
  • 步骤：
  1. 在 /lock 节点下创建一个有序临时节点 (EPHEMERAL_SEQUENTIAL)。
  2. 判断创建的节点序号是否最小，如果是最小则获取锁成功。不是则取锁失败，然后 watch 序号比本身小的前一个节点。
  3. 当取锁失败，设置 watch 后则等待 watch 事件到来后，再次判断是否序号最小。
  4. 取锁成功则执行代码，最后释放锁（删除该节点）。

优缺点

优点：

有效的解决单点问题，不可重入问题，非阻塞问题以及锁无法释放的问题。实现起来较为简单。

缺点：

性能上可能并没有缓存服务那么高，因为每次在创建锁和释放锁的过程中，都要动态创建、销毁临时节点来实现锁功能。ZK 中创建和删除节点只能通过 Leader 服务器来执行，然后将数据同步到所有的 Follower 机器上。还需要对 ZK的原理有所了解。

基于 Consul 做分布式锁

DD 写过类似文章，其实主要利用 Consul 的 Key / Value 存储 API 中的 acquire 和 release 操作来实现。

文章地址：http://blog.didispace.com/spring-cloud-consul-lock-and-semphore/

使用分布式锁的注意事项

1、注意分布式锁的开销

2、注意加锁的粒度

3、加锁的方式

总结

无论你身处一个什么样的公司，最开始的工作可能都需要从最简单的做起。不要提阿里和腾讯的业务场景 qps 如何大，因为在这样的大场景中你未必能亲自参与项目，亲自参与项目未必能是核心的设计者，是核心的设计者未必能独自设计。希望大家能根据自己公司业务场景，选择适合自己项目的方案。

参考资料

http://www.hollischuang.com/archives/1716

http://www.spring4all.com/question/158

https://www.cnblogs.com/PurpleDream/p/5559352.html

http://www.cnblogs.com/PurpleDream/p/5573040.html

https://www.cnblogs.com/suolu/p/6588902.html

从零开始搭建创业公司后台技术栈

JAVA, Web, 架构

有点眼晕，以上只是我们会用到的一些语言的合集，而且只是语言层面的一部分，就整个后台技术栈来说，这只是一个开始，从语言开始，还有很多很多的内容。今天要说的后台是大后台的概念，放在服务器上的东西都属于后台的东西，比如使用的框架，语言，数据库，服务，操作系统等等，整个后台技术栈我的理解包括4个层面的内容：

  • 语言： 用了哪些开发语言，如：c++/java/go/php/python/ruby等等；
  • 组件：用了哪些组件，如：MQ组件，数据库组件等等；
  • 流程：怎样的流程和规范，如：开发流程，项目流程，发布流程，监控告警流程，代码规范等等；
  • 系统：系统化建设，上面的流程需要有系统来保证，如：规范发布流程的发布系统，代码管理系统等等；

结合以上的的4个层面的内容，整个后台技术栈的结构如图2所示：

[图2 后台技术栈结构]

以上的这些内容都需要我们从零开始搭建，在创业公司，没有大公司那些完善的基础设施，需要我们从开源界，从云服务商甚至有些需要自己去组合，去拼装，去开发一个适合自己的组件或系统以达成我们的目标。咱们一个个系统和组件的做选型，最终形成我们的后台技术栈。

一、各系统组件选型

1、项目管理/Bug管理/问题管理

项目管理软件是整个业务的需求，问题，流程等等的集中地，大家的跨部门沟通协同大多依赖于项目管理工具。有一些 SAAS 的项目管理服务可以使用，但是很多时间不满足需求，此时我们可以选择一些开源的项目，这些项目本身有一定的定制能力，有丰富的插件可以使用，一般的创业公司需求基本上都能得到满足，常用的项目如下：

  • Redmine： 用 Ruby 开发的，有较多的插件可以使用，能自定义字段，集成了项目管理，BUG 问题跟踪，WIKI 等功能，不过好多插件 N 年没有更新了;
  • Phabricator: 用 PHP 开发的，facebook 之前的内部工具，开发这工具的哥们离职后自己搞了一个公司专门做这个软件，集成了代码托管， Code Review，任务管理，文档管理，问题跟踪等功能，强烈推荐较敏捷的团队使用；
  • Jira：用 Java 开发的，有用户故事，task 拆分，燃尽图等等，可以做项目管理，也可以应用于跨部门沟通场景，较强大；
  • 悟空CRM ：这个不是项目管理，这个是客户管理，之所以在这里提出来，是因为在 To B 的创业公司里面，往往是以客户为核心来做事情的，可以将项目管理和问题跟进的在悟空 CRM 上面来做，他的开源版本已经基本实现了 CR< 的核心 功能，还带有一个任务管理功能，用于问题跟进，不过用这个的话，还是需要另一个项目管理的软件协助，顺便说一嘴，这个系统的代码写得很难维护，只能适用于客户规模小（1万以内）时。

2、DNS

DNS 是一个很通用的服务，创业公司基本上选择一个合适的云厂商就行了，国内主要是两家：

  • 阿里万网：阿里 2014 年收购了万网，整合了其域名服务，最终形成了现在的阿里万网，其中就包含 DNS 这块的服务；
  • 腾讯 DNSPod: 腾讯 2012 年以 4000 万收购 DNSPod 100% 股份，主要提供域名解析和一些防护功能；

如果你的业务是在国内，主要就是这两家，选 一个就好，像今日头条这样的企业用的也是 DNSPod 的服务，除非一些特殊的原因才需要自建，比如一些 CDN 厂商，或者对区域有特殊限制的。要实惠一点用阿里最便宜的基础版就好了，要成功率高一些，还是用DNSPod 的贵的那种。

在国外还是选择亚马逊吧，阿里的 DNS 服务只有在日本和美国有节点，东南亚最近才开始部点， DNSPod 也只有美国和日本，像一些出海的企业，其选择的云服务基本都是亚马逊。

如果是线上产品，DNS 强烈建议用付费版，阿里的那几十块钱的付费版基本可以满足需求。如果还需要一些按省份或按区域调试的逻辑，则需要加钱，一年也就几百块，省钱省力。

如果是国外，优先选择亚马逊，如果需要国内外互通并且有自己的 APP 的话，建议还是自己实现一些容灾逻辑或者智能调度，因为没有一个现成的 DNS 服务能同时较好的满足国内外场景，或者用多个域名，不同的域名走不同的 DNS 。

3、LB(负载均衡)

LB(负载均衡)是一个通用服务，一般云厂商的 LB 服务基本都会如下功能：

  • 支持四层协议请求（包括 TCP、UDP 协议）;
  • 支持七层协议请求（包括 HTTP、HTTPS 协议）;
  • 集中化的证书管理系统支持 HTTPS 协议;
  • 健康检查;

如果你线上的服务机器都是用的云服务，并且是在同一个云服务商的话，可以直接使用云服务商提供的 LB 服务，如阿里云的 SLB，腾讯云的 CLB， 亚马逊 的 ELB 等等。如果是自建机房基本都是 LVS + Nginx。

4、CDN

CDN 现在已经是一个很红很红的市场，基本上只能挣一些辛苦钱，都是贴着成本在卖。国内以网宿为龙头，他们家占据整个国内市场份额的40%以上，后面就是腾讯，阿里。网宿有很大一部分是因为直播的兴起而崛起。

国外，Amazon 和 Akamai 合起来占比大概在 50%，曾经的国际市场老大 Akamai 拥有全球超一半的份额，在 Amazon CDN入局后，份额跌去了将近 20%，众多中小企业都转向后者，Akamai 也是无能为力。

国内出海的 CDN 厂商，更多的是为国内的出海企业服务，三家大一点的 CDN 服务商里面也就网宿的节点多一些，但是也多不了多少。阿里和腾讯还处于前期阶段，仅少部分国家有节点。

就创业公司来说，CDN 用腾讯云或阿里云即可，其相关系统较完善，能轻松接入，网宿在系统支持层面相对较弱一些，而且还贵一些。并且，当流量上来后，CDN 不能只用一家，需要用多家，不同的 CDN 在全国的节点覆盖不一样，而且针对不同的客户云厂商内部有些区分客户集群，并不是全节点覆盖（但有些云厂商说自己是全网节点），除了节点覆盖的问题，多 CDN 也在一定程度上起到容灾的作用。

5、RPC框架

维基百科对 RPC 的定义是：远程过程调用（Remote Procedure Call，RPC）是一个计算机通信协议。该协议允许运行于一台计算机的程序调用另一台计算机的子程序，而程序员无需额外地为这个交互作用编程。

通俗来讲，一个完整的RPC调用过程，就是 Server 端实现了一个函数，客户端使用 RPC 框架提供的接口，调用这个函数的实现，并获取返回值的过程。

业界 RPC 框架大致分为两大流派，一种侧重跨语言调用，另一种是偏重服务治理。

跨语言调用型的 RPC 框架有 Thrift、gRPC、Hessian、Hprose 等。这类 RPC 框架侧重于服务的跨语言调用，能够支持大部分的语言进行语言无关的调用，非常适合多语言调用场景。但这类框架没有服务发现相关机制，实际使用时需要代理层进行请求转发和负载均衡策略控制。

其中，gRPC 是 Google 开发的高性能、通用的开源 RPC 框架，其由 Google 主要面向移动应用开发并基于 HTTP/2 协议标准而设计，基于 ProtoBuf(Protocol Buffers) 序列化协议开发，且支持众多开发语言。本身它不是分布式的，所以要实现框架的功能需要进一步的开发。

Hprose(High Performance Remote Object Service Engine) 是一个 MIT 开源许可的新型轻量级跨语言跨平台的面向对象的高性能远程动态通讯中间件。

服务治理型的 RPC 框架的特点是功能丰富，提供高性能的远程调用、服务发现及服务治理能力，适用于大型服务的服务解耦及服务治理，对于特定语言(Java)的项目可以实现透明化接入。缺点是语言耦合度较高，跨语言支持难度较大。国内常见的冶理型 RPC 框架如下：

  • Dubbo: Dubbo 是阿里巴巴公司开源的一个 Java 高性能优秀的服务框架，使得应用可通过高性能的 RPC 实现服务的输出和输入功能，可以和 Spring 框架无缝集成。当年在淘宝内部，Dubbo 由于跟淘宝另一个类似的框架 HSF 有竞争关系，导致 Dubbo 团队解散，最近又活过来了，有专职同学投入。
  • DubboX: DubboX 是由当当在基于 Dubbo 框架扩展的一个 RPC 框架，支持 REST 风格的远程调用、Kryo/FST 序列化，增加了一些新的feature。
  • Motan: Motan 是新浪微博开源的一个 Java 框架。它诞生的比较晚，起于 2013 年，2016 年 5 月开源。Motan 在微博平台中已经广泛应用，每天为数百个服务完成近千亿次的调用。
  • rpcx: rpcx 是一个类似阿里巴巴 Dubbo 和微博  Motan 的分布式的 RPC 服务框架，基于 Golang net/rpc 实现。但是 rpcx 基本只有一个人在维护，没有完善的社区，使用前要慎重，之前做 Golang 的 RPC 选型时也有考虑这个，最终还是放弃了，选择了 gRPC，如果想自己自研一个 RPC 框架，可以参考学习一下。

6、名字发现/服务发现

名字发现和服务发现分为两种模式，一个是客户端发现模式，一种是服务端发现模式。

框架中常用的服务发现是客户端发现模式。

所谓服务端发现模式是指客户端通过一个负载均衡器向服务发送请求，负载均衡器查询服务注册表并把请求路由到一台可用的服务实例上。现在常用的负载均衡器都是此类模式，常用于微服务中。

所有的名字发现和服务发现都要依赖于一个可用性非常高的服务注册表，业界常用的服务注册表有如下三个：

  • etcd，一个高可用、分布式、一致性、key-value方式的存储，被用在分享配置和服务发现中。两个著名的项目使用了它：k8s和Cloud Foundry。
  • consul，一个发现和配置服务的工具，为客户端注册和发现服务提供了API，Consul还可以通过执行健康检查决定服务的可用性。
  • Apache Zookeeper，是一个广泛使用、高性能的针对分布式应用的协调服务。Apache Zookeeper本来是 Hadoop 的子工程，现在已经是顶级工程了。

除此之外也可以自己实现服务实现，或者用 Redis 也行，只是需要自己实现高可用性。

7、关系数据库

关系数据库分为两种，一种是传统关系数据，如 Oracle, MySQL，Maria, DB2，PostgreSQL 等等，另一种是 NewSQL，即至少要满足以下五点的新型关系数据库：

  1. 完整地支持SQL，支持JOIN / GROUP BY /子查询等复杂SQL查询；
  2. 支持传统数据标配的 ACID 事务，支持强隔离级别。
  3. 具有弹性伸缩的能力，扩容缩容对于业务层完全透明。
  4. 真正的高可用，异地多活、故障恢复的过程不需要人为的接入，系统能够自动地容灾和进行强一致的数据恢复。
  5. 具备一定的大数据分析能力

传统关系数据库用得最多的是 MySQL，成熟，稳定，一些基本的需求都能满足，在一定数据量级之前基本单机传统数据库都可以搞定，而且现在较多的开源系统都是基于 MySQL，开箱即用，再加上主从同步和前端缓存，百万 pv 的应用都可以搞定了。不过 CentOS 7 已经放弃了 MySQL，而改使用 MariaDB。MariaDB 数据库管理系统是 MySQ L的一个分支，主要由开源社区在维护，采用GPL 授权许可。开发这个分支的原因之一是：甲骨文公司收购了 MySQL 后，有将 MySQ L闭源的潜在风险，因此社区采用分支的方式来避开这个风险。

在 Google 发布了  F1: A Distributed SQL Database That Scales 和  Spanner: Google’s Globally-Distributed Databasa 之后，业界开始流行起 NewSQL。于是有了 CockroachDB，于是有了 奇叔公司的 TiDB。国内已经有比较多的公司使用 TiDB，之前在创业公司时在大数据分析时已经开始应用 TiDB，当时应用的主要原因是 MySQL 要使用分库分表，逻辑开发比较复杂，扩展性不够。

8、NoSQL

NoSQL 顾名思义就是 Not-Only SQL，也有人说是 No – SQL, 个人偏向于Not – Only SQL,它并不是用来替代关系库，而是作为关系型数据库的补充而存在。

常见 NoSQL 有4个类型：

  1. 键值，适用于内容缓存，适合混合工作负载并发高扩展要求大的数据集，其优点是简单，查询速度快，缺点是缺少结构化数据，常见的有 Redis, Memcache, BerkeleyDB 和 Voldemort 等等；
  2. 列式，以列簇式存储，将同一列数据存在一起，常见于分布式的文件系统，其中以 Hbase，Cassandra 为代表。Cassandra 多用于写多读少的场景，国内用得比较多的有 360，大概 1500 台机器的集群，国外大规模使用的公司比较多，如 Ebay，Instagram，Apple 和沃尔玛等等；
  3. 文档，数据存储方案非常适用承载大量不相关且结构差别很大的复杂信息。性能介于 kv 和关系数据库之间，它的灵感来于 lotus notes，常见的有 MongoDB，CouchDB 等等；
  4. 图形，图形数据库擅长处理任何涉及关系的状况。社交网络，推荐系统等。专注于构建关系图谱，需要对整个图做计算才能得出结果，不容易做分布式的集群方案，常见的有 Neo4J，InfoGrid 等。

除了以上4种类型，还有一些特种的数据库，如对象数据库，XML 数据库，这些都有针对性对某些存储类型做了优化的数据库。

在实际应用场景中，何时使用关系数据库，何时使用 NoSQL，使用哪种类型的数据库，这是我们在做架构选型时一个非常重要的考量，甚至会影响整个架构的方案。

9、消息中间件

消息中间件在后台系统中是必不可少的一个组件，一般我们会在以下场景中使用消息中间件：

  • 异步处理：异步处理是使用消息中间件的一个主要原因，在工作中最常见的异步场景有用户注册成功后需要发送注册成功邮件、缓存过期时先返回老的数据，然后异步更新缓存、异步写日志等等；通过异步处理，可以减少主流程的等待响应时间，让非主流程或者非重要业务通过消息中间件做集中的异步处理。
  • 系统解耦：比如在电商系统中，当用户成功支付完成订单后，需要将支付结果给通知ERP系统、发票系统、WMS、推荐系统、搜索系统、风控系统等进行业务处理；这些业务处理不需要实时处理、不需要强一致，只需要最终一致性即可，因此可以通过消息中间件进行系统解耦。通过这种系统解耦还可以应对未来不明确的系统需求。
  • 削峰填谷：当系统遇到大流量时，监控图上会看到一个一个的山峰样的流量图，通过使用消息中间件将大流量的请求放入队列，通过消费者程序将队列中的处理请求慢慢消化，达到消峰填谷的效果。最典型的场景是秒杀系统，在电商的秒杀系统中下单服务往往会是系统的瓶颈，因为下单需要对库存等做数据库操作，需要保证强一致性，此时使用消息中间件进行下单排队和流控，让下单服务慢慢把队列中的单处理完，保护下单服务，以达到削峰填谷的作用。

业界消息中间件是一个非常通用的东西，大家在做选型时有使用开源的，也有自己造轮子的，甚至有直接用 MySQL 或 Redis 做队列的，关键看是否满足你的需求，如果是使用开源的项目，以下的表格在选型时可以参考：

[图3]

以上图的纬度为：名字 成熟度所属社区/公司 文档 授权方式 开发语言支持的协议 客户端支持的语言 性能 持久化 事务 集群 负载均衡 管理界面 部署方式 评价

10 、代 码管理

代码是互联网创业公司的命脉之一，代码管理很重要，常见的考量点包括两块：

  • 安全和权限管理，将代码放到内网并且对于关系公司命脉的核心代码做严格的代码控制和机器的物理隔离；
  • 代码管理工具，Git 作为代码管理的不二之选，你值得拥有。Gitlab 是当今最火的开源 Git 托管服务端，没有之一，虽然有企业版，但是其社区版基本能满足我们大部分需求，结合 Gerrit 做 Code review，基本就完美了。当然 Gitlab 也有代码对比，但没Gerrit 直观。Gerrit 比 Gitlab 提供了更好的代码检查界面与主线管理体验，更适合在对代码质量有高要求的文化下使用。

11、持续集成

持续集成简，称 CI(continuous integration)， 是一种软件开发实践，即团队开发成员经常集成他们的工作，每天可能会发生多次集成。每次集成都通过自动化的构建（包括编译，发布，自动化测试）来验证，从而尽早地发现集成错误。持续集成为研发流程提供了代码分支管理/比对、编译、检查、发布物输出等基础工作，为测试的覆盖率版本编译、生成等提供统一支持。

业界免费的持续集成工具中系统我们有如下一些选择：

  • Jenkins：Jjava写的 有强大的插件机制，MIT协议开源 （免费，定制化程度高，它可以在多台机器上进行分布式地构建和负载测试）。Jenkins可以算是无所不能，基本没有 Jenkins 做不了的，无论从小型团队到大型团队 Jenkins 都可以搞定。 不过如果要大规模使用，还是需要有人力来学习和维护。
  • TeamCity： TeamCity与Jenkins相比使用更加友好，也是一个高度可定制化的平台。但是用的人多了，TeamCity就要收费了。
  • Strider： Strider 是一个开源的持续集成和部署平台，使用 Node.js 实现，存储使用的是 MongoDB，BSD 许可证，概念上类似 Travis 和Jenkins。
  • GitLabCI：从GitLab8.0开始，GitLab CI 就已经集成在 GitLab，我们只要在项目中添加一个 .gitlab-ci.yml 文件，然后添加一个Runner，即可进行持续集成。并且 Gitlab 与 Docker 有着非常好的相互协作的能力。免费版与付费版本不同可以参见这里： https://about.gitlab.com/products/feature-comparison/
  • Travis：Travis 和 Github 强关联；闭源代码使用 SaaS 还需考虑安全问题； 不可定制；开源项目免费，其它收费；
  • Go: Go是ThoughtWorks公司最新的Cruise Control的化身。除了 ThoughtWorks 提供的商业支持，Go是免费的。它适用于Windows，Mac和各种Linux发行版。

12、日志系统

日志系统一般包括打日志，采集，中转，收集，存储，分析，呈现，搜索还有分发等。一些特殊的如染色，全链条跟踪或者监控都可能需要依赖于日志系统实现。日志系统的建设不仅仅是工具的建设，还有规范和组件的建设，最好一些基本的日志在框架和组件层面加就行了，比如全链接跟踪之类的。

对于常规日志系统ELK能满足大部分的需求，ELK 包括如下组件：

  • ElasticSearch 是个开源分布式搜索引擎，它的特点有：分布式，零配置，自动发现，索引自动分片，索引副本机制，restful风格接口，多数据源，自动搜索负载等。
  • Logstash 是一个完全开源的工具，它可以对你的日志进行收集、分析，并将其存储供以后使用。
  • Kibana 是一个开源和免费的工具，它可以为 Logstash 和 ElasticSearch 提供的日志分析友好的 Web 界面，可以帮助汇总、分析和搜索重要数据日志。

Filebeat 已经完全替代了 Logstash-Forwarder 成为新一代的日志采集器，同时鉴于它轻量、安全等特点，越来越多人开始使用它。

因为免费的 ELK 没有任何安全机制，所以这里使用了 Nginx 作反向代理，避免用户直接访问 Kibana 服务器。加上配置 Nginx 实现简单的用户认证，一定程度上提高安全性。另外，Nginx 本身具有负载均衡的作用，能够提高系统访问性能。ELK 架构如图4所示：

[图4] ELK 流程图

对于有实时计算的需求，可以使用 Flume+Kafka+Storm+MySQL方案，一 般架构如图5所示：

[图5] 实时分析系统架构图

其中：

  • Flume 是一个分布式、可靠、和高可用的海量日志采集、聚合和传输的日志收集系统，支持在日志系统中定制各类数据发送方，用于收集数据;同时，Flume 提供对数据进行简单处理，并写到各种数据接受方(可定制)的能力。
  • Kafka 是由 Apache 软件基金会开发的一个开源流处理平台，由 Scala 和 Java 编写。其本质上是一个“按照分布式事务日志架构的大规模发布/订阅消息队列”，它以可水平扩展和高吞吐率而被广泛使用。

Kafka 追求的是高吞吐量、高负载，Flume 追求的是数据的多样性，二者结合起来简直完美。

13、监控系统

监控系统只包含与后台相关的，这里主要是两块，一个是操作系统层的监控，比如机器负载，IO，网络流量，CPU，内存等操作系统指标的监控。另一个是服务质量和业务质量的监控，比如服务的可用性，成功率，失败率，容量，QPS 等等。常见业务的监控系统先有操作系统层面的监控（这部分较成熟），然后扩展出其它监控，如 zabbix，小米的 open-falcon，也有一出来就是两者都支持的，如 prometheu s。如果对业务监控要求比较高一些，在创业选型中建议可以优先考虑 prometheus。这里有一个有趣的分布，如图6所示

[图6 监控系统分布]

亚洲区域使用 zabbix 较多，而美洲和欧洲，以及澳大利亚使用 prometheus 居多，换句话说，英文国家地区（发达国家？）使用prometheus 较多。

Prometheus 是由 SoundCloud 开发的开源监控报警系统和时序列数据库( TSDB )。Prometheus 使用 Go 语言开发，是 Google BorgMon 监控系统的开源版本。相对于其它监控系统使用的 push 数据的方式，prometheus 使用的是 pull 的方式，其架构如图7所示：

[图7] prometheus架构图

如上图所示，prometheus 包含的主要组件如下：

  • Prometheus Server 主要负责数据采集和存储，提供 PromQL 查询语言的支持。Server 通过配置文件、文本文件、Zookeeper、Consul、DNS SRV Lookup等方式指定抓取目标。根据这些目标会，Server 定时去抓取 metric s数据，每个抓取目标需要暴露一个 http 服务的接口给它定时抓取。
  • 客户端SDK：官方提供的客户端类库有 go、java、scala、python、ruby，其他还有很多第三方开发的类库，支持 nodejs、php、erlang 等。
  • Push Gateway 支持临时性 Job 主动推送指标的中间网关。
  • Exporter Exporter 是Prometheus的一类数据采集组件的总称。它负责从目标处搜集数据，并将其转化为 Prometheus 支持的格式。与传统的数据采集组件不同的是，它并不向中央服务器发送数据，而是等待中央服务器主动前来抓取。Prometheus提供多种类型的 Exporter 用于采集各种不同服务的运行状态。目前支持的有数据库、硬件、消息中间件、存储系统、HTTP服务器、JMX等。
  • alertmanager：是一个单独的服务，可以支持 Prometheus 的查询语句，提供十分灵活的报警方式。
  • Prometheus HTTP API的查询方式，自定义所需要的输出。
  • Grafana 是一套开源的分析监视平台，支持 Graphite, InfluxDB, OpenTSDB, Prometheus, Elasticsearch, CloudWatch 等数据源，其 UI 非常漂亮且高度定制化。

创业公司选择 Prometheus + Grafana 的方案，再加上统一的服务框架(如 gRPC )，可以满足大部分中小团队的监控需求。

14、配置系统

随着程序功能的日益复杂，程序的配置日益增多：各种功能的开关、降级开关，灰度开关，参数的配置、服务器的地址、数据库配置等等，除此之外，对后台程序配置的要求也越来越高：配置修改后实时生效，灰度发布，分环境、分用户，分集群管理配置，完善的权限、审核机制等等，在这样的大环境下，传统的通过配置文件、数据库等方式已经越来越无法满足开发人员对配置管理的需求，业界有如下两种方案：

  • 基于 zk 和 etcd，支持界面和 api ，用数据库来保存版本历史，预案，走审核流程，最后下发到 zk 或 etcd 这种有推送能力的存储里（服务注册本身也是用 zk 或 etcd，选型就一块了）。客户端都直接和 zk 或 etcd 打交道。至于灰度发布，各家不同，有一种实现是同时发布一个需要灰度的 IP 列表，客户端监听到配置节点变化时，对比一下自己是否属于该列表。PHP 这种无状态的语言和其他 zk/etcd 不支持的语言，只好自己在客户端的机器上起一个 Agent 来监听变化，再写到配置文件或共享内存，如 360 的 Qconf。
  • 基于运维自动化的配置文件的推送，审核流程，配置数据管理和方案一类似，下发时生成配置文件，基于运维自动化工具如Puppet，Ansible 推送到每个客户端，而应用则定时重新读取这个外部的配置文件，灰度发布在下发配置时指定IP列表。

创业公司前期不需要这种复杂，直接上 zk，弄一个界面管理 zk 的内容，记录一下所有人的操作日志，程序直连 zk，或者或者用Qconf 等基于 zk 优化后的方案。

15、发布系统/部署系统

从软件生产的层面看，代码到最终服务的典型流程如图8所示：

[图8 流程图]

从上图中可以看出，从开发人员写下代码到服务最终用户是一个漫长过程，整体可以分成三个阶段：

  • 从代码（Code）到成品库（Artifact）这个阶段主要对开发人员的代码做持续构建并把构建产生的制品集中管理，是为部署系统准备输入内容的阶段。
  • 从制品到可运行服务 这个阶段主要完成制品部署到指定环境，是部署系统的最基本工作内容。
  • 从开发环境到最终生产环境 这个阶段主要完成一次变更在不同环境的迁移，是部署系统上线最终服务的核心能力。

发布系统集成了制品管理，发布流程，权限控制，线上环境版本变更，灰度发布，线上服务回滚等几方面的内容，是开发人员工作结晶最终呈现的重要通道。开源的项目中没有完全满足的项目，如果只是 Web 类项目，Walle、Piplin 都是可用的，但是功能不太满足，创业初期可以集成 Jenkins + Gitlab + Walle (可以考虑两天时间完善一下)，以上方案基本包括 制品管理，发布流程，权限控制，线上环境版本变更，灰度发布（需要自己实现），线上服务回滚等功能。

16、跳板机

跳板机面对的是需求是要有一种能满足角色管理与授权审批、信息资源访问控制、操作记录和审计、系统变更和维护控制要求，并生成一些统计报表配合管理规范来不断提升IT内控的合规性，能对运维人员操作行为的进行控制和审计，对误操作、违规操作导致的操作事故，快速定位原因和责任人。其功能模块一般包括：帐户管理、认证管理、授权管理、审计管理等等

开源项目中，Jumpserver 能够实现跳板机常见需求，如授权、用户管理、服务器基本信息记录等，同时又可批量执行脚本等功能；其中录像回放、命令搜索、实时监控等特点，又能帮助运维人员回溯操作历史，方便查找操作痕迹，便于管理其他人员对服务器的操作控制。

17、机器管理

机器管理的工具选择的考量可以包含以下三个方面：

  1. 是否简单，是否需要每台机器部署agent（客户端）
  2. 语言的选择（puppet/chef vsansible/saltstack）开源技术，不看官网不足以熟练，不懂源码不足以精通；Puppet、Chef基于Ruby开发，ansible、saltstack基于python开发的
  3. 速度的选择(ansiblevssaltstack) ansible基于SSH协议传输数据，Saltstack使用消息队列zeroMQ传输数据；大规模并发的能力对于几十台-200台规模的兄弟来讲，ansible的性能也可接受，如果一次操作上千台，用salt好一些。

如图9所示：

[图9 机器管理软件对比]

一般创业公司选择 Ansible 能解决大部问题，其简单，不需要安装额外的客户端，可以从命令行来运行，不需要使用配置文件。至于比较复杂的任务，Ansible 配置通过名为 Playbook 的配置文件中的 YAML 语法来加以处理。Playbook 还可以使用模板来扩展其功能。

二、创业公司的选择

1、选择合适的语言

  • 选择团队熟悉的/能掌控的，创业公司人少事多，无太多冗余让研发团队熟悉新的语言，能快速上手，能快速出活，出了问题能快速解决的问题的语言才是好的选择。
  • 选择更现代一些的，这里的现代是指语言本身已经完成一些之前需要特殊处理的特性，比如内存管理，线程等等。
  • 选择开源轮子多的或者社区活跃度高的，这个原则是为了保证在开发过程中减少投入，有稳定可靠的轮子可以使用，遇到问题可以在网上快速搜索到答案。
  • 选择好招人的 一门合适的语言会让创业团队减少招聘的成本，快速招到合适的人。
  • 选择能让人有兴趣的 与上面一点相关，让人感兴趣，在后面留人时有用。

2、选择合适的组件和云服务商

  • 选择靠谱的云服务商；
  • 选择云服务商的组件；
  • 选择成熟的开源组件，而不是最新出的组件；
  • 选择采用在一线互联网公司落地并且开源的，且在社区内形成良好口碑的产品；
  • 开源社区活跃度；

选择靠谱的云服务商，其实这是一个伪命题，因为哪个服务商都不靠谱，他们所承诺的那些可用性问题基本上都会在你的身上发生，这里我们还是需要自己做一些工作，比如多服务商备份，如用CDN，你一定不要只选一家，至少选两家，一个是灾备，保持后台切换的能力，另一个是多点覆盖，不同的服务商在CDN节点上的资源是不一样的。

选择了云服务商以后，就会有很多的产品你可以选择了，比较存储，队列这些都会有现成的产品，这个时候就纠结了，是用呢？还是自己在云主机上搭呢？在这里我的建议是前期先用云服务商的，大了后再自己搞，这样会少掉很多运维的事情，但是这里要多了解一下云服务商的组件特性以及一些坑，比如他们内网会经常断开，他们升级也会闪断，所以在业务侧要做好容错和规避。

关于开源组件，尽可能选择成熟的，成熟的组件经历了时间的考验，基本不会出大的问题，并且有成套的配套工具，出了问题在网上也可以很快的找到答案，你所遇到的坑基本上都有人踩过了。

3、制定流程和规范

  • 制定开发的规范，代码及代码分支管理规范，关键性代码仅少数人有权限；
  • 制定发布流程规范，从发布系统落地；
  • 制定运维规范；
  • 制定数据库操作规范，收拢数据库操作权限；
  • 制定告警处理流程，做到告警有人看有人处理；
  • 制定汇报机制，晨会/周报；

4、自研和选型合适的辅助系统

所有的流程和规范都需要用系统来固化，否则就是空中楼阁，如何选择这些系统呢？参照上个章节咱们那些开源的，对比一下选择的语言，组件之类的，选择一个最合适的即可。

比如项目管理的，看下自己是什么类型的公司，开发的节奏是怎样的，瀑布，敏捷的 按项目划分，还是按客户划分等等，平时是按项目组织还是按任务组织等等

比如日志系统，之前是打的文本，那么上一个elk，规范化一些日志组件，基本上很长一段时间内不用考虑日志系统的问题，最多拆分一下或者扩容一下。等到组织大了，自己搞一个日志系统。

比如代码管理，项目管理系统这些都放内网，安全，在互联网公司来说，属于命脉了，命脉的东西还是放在别人拿不到或很难拿到的地方会比较靠谱一些。

5、选择过程中需要思考的问题

技术栈的选择有点像做出了某种承诺，在一定的时间内这种承诺没法改变，于是我们需要在选择的时候有一些思考。

看前面内容，有一个词出现了三次，合适，选择是合适的，不是最好，也不是最新，是最合适，适合是针对当下，这种选择是最合适的吗？比如用 Go 这条线的东西，技术比较新，业界组件储备够吗？组织内的人员储备够吗？学习成本多少？写出来的东西能满足业务性能要求吗？能满足时间要求吗？

向未来看一眼，在一年到三年内，我们需要做出改变吗？技术栈要做根本性的改变吗？如果组织发展很快，在 200 人，500 人时，现有的技术栈是否需要大动？

创业过程中需要考虑成本，这里的成本不仅仅是花费多少钱，付出多少工资，有时更重要的是时间成本，很多业务在创业时大家拼的就是时间，就是一个时间窗，过了就没你什么事儿了。

三、基于云的创业公司后台技术架构

结合上面内容的考量，在对一个个系统和组件的做选型之后，以云服务为基础，一个创业公司的后台技术架构如图10所示：

[图10 后台技术架构]

参考资料

http://database.51cto.com/art/201109/291781.htm

https://zh.wikipedia.org/wiki/Kafka

https://prometheus.io/docs/introduction/overview/

http://deadline.top/2016/11/23/配置中心那点事/

http://blog.fit2cloud.com/2016/01/26/deployment-system.html

from:http://www.phppan.com/2018/04/svr-stack/

HTTP协议冷知识大全

Web, ,

如果不用HTTPS，HTTP协议如何安全的传输密码信息？

HTTP协议是纯文本协议，没有任何加密措施。通过HTTP协议传输的数据都可以在网络上被完全监听。如果用户登陆时将用户名和密码直接明文通过HTTP协议传输过去了，那么密码可能会被黑客窃取。
一种方法是使用非对称加密。GET登陆页面时，将公钥以Javascript变量的形式暴露给浏览器。然后用公钥对用户的密码加密后，再将密码密文、用户名和公钥一起发送给服务器。服务器会提前存储公钥和私钥的映射信息，通过客户端发过来的公钥就可以查出对应的私钥，然后对密码密文进行解密就可以还原出密码的明文。
为了加强公钥私钥的安全性，服务器应该动态生成公钥私钥对，并且使用后立即销毁。但是动态生成又是非常耗费计算资源的，所以一般服务器会选择Pool方法提供有限数量的公钥私钥对池，然后每隔一段时间刷新一次Pool。

640文件路径攻击

很多操作系统都会使用..符号表示上层目录。如果黑客在URL的路径里面使用..符号引用上层目录，而服务器没有做好防范的话就有可能导致黑客可以直接访问权限之外的文件。比如使用多级..符号就可以引用到根目录，进一步就可以访问任意文件。
所以很多服务器都禁止在URL路径里出现..符号以避免被攻击。
文件路径攻击也是很多黑客非常喜爱使用的攻击方法之一。如果你的服务器有一定的访问量，打开你的nginx日志，你就会偶尔发现有一些奇怪的URL里面有一堆..符号，这种URL的出现就表示网络上的黑客正在尝试攻击你的服务器。

DNS欺骗

HTTP协议严重依赖于DNS域名解析。任意一个域名类网址的访问都需要经过域名解析的过程得到目标服务的IP地址才能成功继续下去。
如果掌管DNS服务的运营商作恶将域名解析到不正确的IP，指向一个钓鱼的网页服务。用户如果没有觉察，就可能会将自己的敏感信息提交给冒牌的服务器。

642谨慎使用外部的HTTP代理

HTTP代理作为客户端到服务器之间的中间路由节点，它起到传话人和翻译官的角色。
如果这个翻译官不靠谱的话，客户端是会拿到错误的返回数据的。它同DNS欺骗一样，是可以对客户端进行钓鱼攻击的。
如果这个翻译官口风不严的话，它可能会将它听到的敏感信息泄露给别人

643413 Request Entity Too Large

客户端上传图片太大超过服务器限制时，服务器返回413错误。

414 Request-URI Too Long

客户端访问的URI太长，超出了服务器允许限制，服务器返回414错误。

202 Accepted

常用于异步请求。客户端发送请求到服务器，服务器立即返回一个202 Accepted表示已经成功接收到客户端的请求。
后面怎么处理由服务器自己决定，一般服务器会给客户端预留一个可以查询处理状态的接口，客户端可以选择轮训该接口来知道请求的处理进度和结果。

POST提交数据的方式

application/x-www-form-urlencoded

提交数据表单时经常使用，Body内部存放的是转码后的键值对。

application/json

提交结构化表单时使用，Body内部存放的是JSON字符串。ElasticSearch的查询协议使用的是这种方式。

multipart/form-data

上传文件时经常使用。这种格式比较复杂，它是为了支持多文件上传混合表单数据而设计的一种特殊的格式。

用户填充了表单设置了待上传的文件，点击Submit，传输数据大致如下

Cookie

浏览器请求的Cookie中往往会携带敏感信息。服务器一般会将当前用户的会话ID存在cookie里，会话的具体内容存在服务器端，会话的内容很敏感。

浏览器请求时会携带Cookie信息，服务器根据Cookie信息中的会话ID找到对应的会话内容。会话内容里可能存储了用户的权限信息，拿到这部分权限信息后就可能随意控制修改用户的数据。

644因为HTTP协议的不安全性，请求数据包很容易被窃听，Cookie中的会话信息很容易被盗。解决方案之一就是在会话中记录用户的终端信息和IP地址信息，如果这些信息突然发生改变，需要强制用户重新认证。

不过高级的黑客是可以伪造出和用户真实请求一摸一样的数据包的。最彻底的解决方案还是采用HTTPS协议。

普通的Cookie信息可以通过Javascript脚本获取到。如果黑客通过某种方式在网页中植入不安全的脚本，将用户的Cookie拿到然后发送到远程的第三方服务器中，那么Cookie中的信息就被泄露了。

Cookie的两个重要属性

被标记为Secure的Cookie信息在HTTP请求中不会被传送，它只会在HTTPS请求中传送，避免数据被泄露。

被标记为HttpOnly的Cookie信息是无法通过Javascript API获取到的，它只会在请求中传送。这样可以避免黑客通过网页脚本方式窃取Cookie中的敏感信息。

Cookie(甜点)如此好吃，黑客们总想通过Cookie做各种文章。

645CSRF(Cross-Site Request Forgery)

CSRF跨站请求伪造有很多别名，比如One-Click Attack(一键攻击)，比如Session Riding(搭便车攻击)

假设在在一个社区博客网站中，删除个人的文章只需要一个URL就可以，Cookie中的会话权限信息会自动附加到请求上。

那么当别人伪造了一个上面的链接地址诱惑你去点击，比如通过站内信件、私聊、博客评论、图片链接或者在别的什么网站上随机制造的一个链接。你不经意点了一下，就丢了你的文章。所以它被称为一键攻击。因为这是借用了你当前登陆的会话信息来搞事，所以也被称为搭便车攻击。

如果在一个金融系统中，转账要是也可以通过一个简单的URL进行的话，那这种危险就非同小可。

646这就要求修改性的操作务必不得使用简单的GET请求进行处理。但是即使这种情况下你改成了POST请求，黑客依然有办法伪造请求，那就是通过iframe。

黑客在别的什么网站上伪造了一个POST表单，诱惑你去submit。如果只是普通的内嵌进HTML网页的表单，用户提交时会出现跨域问题。因为当前网站的域名和表单提交的目标域名不一致。但是如果通过iframe来内嵌表单，则可以绕过跨域的问题，而用户却完全没有任何觉察。

为了防范CSRF攻击，聪明的网站的POST表单里都会带上CSRF_TOKEN这个隐藏字段。CSRF_TOKEN是根据用户的会话信息生成的。当表单提交时，会将token和用户的会话信息做比对。如果匹配就是有效的提交请求。

黑客必须拿到CSRF_TOKEN才可以借用用户的会话信息实施CSRF攻击，但是CSRF_TOKEN又必须由用户的会话信息才可以生成。黑客没有用户的会话信息，从而无法实施CSRF攻击。

XSS(Cross Site Scripting)

如果黑客可以在你的网页中植入任意Javascript脚本，那他就可以随意鱼肉你的账户。通过Javascript可以获取Cookie的信息，可以借用你的会话去调用一些隐秘的API，而这一些行为都是在偷偷的进行，你根本完全不知道。

这类攻击在一些UGC网站中非常常见，常见的博客类网站就是UGC网站，用户可以通过编辑内容来生成网页。

黑客也是用户。他可以编辑一段Javascript脚本作为内容提交上去。如果服务器没有做好防范，这段脚本就会在生成的网页中运行起来。当其它用户在登陆的状态下来浏览这个网页的时候，就悲剧了。

防范XSS一般是通过对输出的内容进行内容替换做到的。在HTML页面中不同的位置会有不同的内容替换规则。
比较常见的是使用HTML entity编码将HTML标签之间的内容中的一些特殊的字符进行转码。

还有些UGC内容在HTML标签的属性中、Javascript的变量中、URL、css代码中，他们转码的规则并不一样，具体方法可以去Google相关文档。

跨域

跨域是个很头痛的问题。

当你有多个后端服务，但是只有一个前端的时候，你想做前后端分离，就会遇到跨域问题。你发现你的前端js调用后端服务时控制台告诉你不ok。然后只好把这些服务都挂在了同一个nginx域名下面，通过url前缀区分。

647这时候你会想，跨域太TM讨厌了。既然跨域这么讨厌，那为什么浏览器非要限制跨域呢？

还是安全原因。

让我们回到上文的搭便车攻击(Session Riding)，也就是骑着别人的会话来搞事情。

假设现在你的浏览器开了一个站点A，登陆了进去，于是cookie便记录了会话id。
然后你又不小心开了另一个站点B，这个站点页面一打开就开始执行一些恶意代码。这些代码的逻辑是调用站点A的API来获取站点A的数据，因为可以骑着(Ride)站点A的会话cookie。而这些数据正好是用户私密性的。于是用户在站点A上的私有信息就被站点B上的代码窃走了。这就是跨域的风险。

但是有时候我们又希望共享数据给不同的站点，该怎么办呢？

答案是JSONP & CORS

JSONP(JSON Padding)

JSONP通过HTML的script标记实现了跨域共享数据的方式。JSON通过在网页里定义一个回调方法，然后在页面上插入一个动态script标签，指向目标调用地址。服务器会返回一段javascript代码，一般是some_callback(data)这种形式的回调。该段代码会在浏览器里自动执行，于是网页就得到了跨域服务器返回的数据。

因为JSONP是不携带cookie信息的，所以能有效避免搭便车攻击。JSONP是否可以获取到数据还需要服务器对这种调用提供显示支持，服务器必须将数据以javascript代码的形式返回才可以传递给浏览器。

CORS(Cross-Origin Resource Sharing)

JSONP的不足在于它只能发送GET请求，并且不能携带cookie。而CORS则可以发送任意类型的请求，可以选择性携带cookie。

CORS是通过Ajax发送的跨域请求技术。CORS的请求分为两种，一种是简单请求，一种是复杂请求。简单请求就是头部很少很简单的GET/HEAD/POST请求。复杂请求就是非简单请求。

浏览器发现Ajax的请求是跨域的，就会在请求头添加一个Origin参数，指明当前请求的发起站点来源。服务器根据Origin参数来决定是否授权。

如果是简单请求，Ajax直接请求服务器。服务器会当成普通的请求直接返回内容，不同的是还会在响应头部添加几个重要的头部，其中最重要的头部是Access-Control-Allow-Origin: http://example.com。

浏览器如果在响应中没有读到这个头部，就会通知Ajax请求失败。虽然服务器返回了数据，浏览器也不让脚本读到数据，这就保证了跨域的安全。服务器就是通过请求的Origin参数来决定要不要响应Access-Control-Allow-Origin头部来决定是否允许指定网站的跨域请求。

如果是复杂请求，要走一个预检的流程。预检就是浏览器先向服务器发送一个Method为Options的请求，如果服务器允许跨域请求，浏览器再发起这个Ajax请求。所以CORS的复杂请求会比简单请求额外耗费一个TTL的时间。

CORS的细节请参见大神阮一峰的博文《跨域资源共享CORS详解》

from:https://mp.weixin.qq.com/s/aekcsgLG6jZw3LeF3R9ssQ

视频编码与封装综述

计算理论,

随着多媒体技术和网络通信技术的快速发展，视频多媒体应用已经覆盖了大众生活的方方面面。尤其是近年来高清和超高清视频应用越来越广泛，相比于标清视频，高清视频分辨率更高、画面更清晰，其数据量也更大。如果未经压缩，这些视频将很难应用于实际的存储和传输。这里我们就要提到视频应用中的一项关键技术——视频压缩编码技术！

 

视频压缩编码技术可以有效地去除视频数据中冗余信息，实现视频数据在互联网中快速传输和离线存储

视频技术起源于第二次工业革命，随着视频技术的发展，一系列的视频编码标准被研发被使用。

压缩标准的变迁
目前已有的视频压缩标准有很多种，包括国际标准化组织（International Organization for Standardization, ISO）/国际电工技术委员会（International Electrotechnical Commission, IEC）制定的MPEG-1、MPEG-2、MPEG-4标准，国际电信联盟电信标准化部门（International Telecommunication Union-Telecom, ITU-T）制定的H.261、H.263。 

2003年3月，ITU-T和ISO/IEC 正式公布了H.264/MPEG-4 AVC视频压缩标准。H.264作为目前应用最为广泛的视频编码标准，在提高编码效率和灵活性方面取得了巨大成功，使得数字视频有效地应用在各种各样的网络类型和工程领域。为了在关键技术上不受国外牵制，同时也不用交大量的专利费用，中国也制定了AVS系列标准，可以提供与H.264/AVC相当的编码效率。

 

随着用户体验的升级，更高码率的视频也在被提供，比如超高清（3840 x 2160）。相对于标清视频，其分辨率更高，数据量也更多。在存储空间和网络带宽有限的情况下，现有的视频压缩技术已经不能满足现实的应用需求。为了解决高清及超高清视频急剧增长的数据率给网络传输和数据存储带来的冲击，ITU-T和ISO/IEC联合制定了具有更高的压缩效率的新一代视频压缩标准HEVC（High Efficiency Video Coding）。

HEVC简单介绍
HEVC：新一代视频压缩标准，以传统的混合视频编码为框架，并采用了更多的技术创新，包括灵活的块划分方式、更精细的帧内预测、新加入的Merge模式、Tile划分、自适应样点补偿等。 

这些技术一方面使得HEVC编码性能比H.264/AVC提高了一倍，另一方面也将编码复杂度大大增加，不利于HEVC的应用和推广。

 

在这里着重说一下块划分方式——对编码性能提升最大。块划分包括编码单元（CU）、预测单元（PU）和变换单元（TU）。但是，递归的对每个编码单元进行率失真优化过程（RDO）来选择最优的模块划分的复杂度很高，其需要巨大的计算复杂度。因此降低HEVC编码复杂度的是视频行业人员所希望看到的。

640
图1 视频编码框图
新一代编码器对比
641
常见的封装格式有以下几种：· AVI(Audio Video Interleave):只能封装一条视频轨和音频轨，不能封装文字，没有任何控制功能，因而也就无法实现流媒体，其文件扩展名是.avi。

· WMV(Windows Media Video):具有数字版权保护功能，其文件扩展名是.wmv/.asf。

· MPEG(Moving Picture Experts Group):可以支持多个视频、音轨、字幕等，控制功能丰富，其文件扩展名是.mp4。

· Matroxska:提供非常好的交互功能，比MPEG更强大，其文件扩展名是.mkv。

· QuickTime File Farmat:由Apple开发，可存储内容丰富，支持视频、音频、图片、文字等，其文件扩展名是.mov。

· FLV(Flash Video):由Adobe Flash延伸而来的一种视频技术，主要用于网站。

· TS流（Transport Stream）：传输流，将具有共同时间基准或独立时间基准的一个或多个PES组合（复合）而成的单一数据流（用于数据传输）。目前TS流广泛应用于广播电视中，如机顶盒等。

总结
本文简单介绍了视频的编码与封装，其是视频通信中重要的一步，如果这一步出了问题，很容易导致视频无法被读取或无法播放的状态。下一节，我们将来说一下视频通信中的音视频处理技术。from:https://mp.weixin.qq.com/s/9hClcofo8HEI8QqDpef12Q

想要做”架构师“，一定要会画设计图

架构,

什么是系统架构师？

系统架构师是一个既需要掌控整体又需要洞悉局部瓶颈并依据具体的业务场景给出解决方案的团队领导型人物。一个架构师得需要足够的想像力,能把各种目标需求进行不同维度的扩展，为目标客户提供更为全面的需求清单。

架构师在软件开发的整个过程中起着很重要的作用。

如何才能成为系统架构师？

1. 首先必须具有丰富的软件设计与开发经验，这有助于理解并解释所进行的设计是如何映射到实现中去。

2. 其次要具有领导能力与团队协作技能，软件架构师必须是一个得到承认的技术领导，能在关键时候对技术的选择作出及时、有效的决定。

3. 第三是具有很强的沟通能力，其实这一点好像什么角色都最好具备，软件架构师需要与各路人马经常打交道，客户、市场人员、开发人员、测试人员、项目经理、网络管理员、数据库工程师等等，而且在很多角色之间还要起沟通者的作用。

而设计图，它不是简单的供你欣赏，他其实是架构师，产品经理，开发工程师，测试工程师等各种角色之间进行沟通的语言，沟通的一个桥梁，让整个团队更能有效的协调工作。

设计图不单单是架构师要掌握的，在一个产品的开发过程中，任何一个环节，任何一个角色都可以通过掌握不同的设计图来完成沟通的。

流程图

流程是一系列的逻辑关系（包含因果关系、时间先后、必要条件、输入输出）产品经理做需求前一定要先把这些逻辑关系理清楚，如果非要用一句话概括的话“流程就是在特定的情境下满足用户特定需要的总结”。

图就是将你头脑中的逻辑关系以图形化的形式呈现出来，具有图形化、可视化的特点，因为是图，你可以像你的版本迭代一样，当你的逻辑需要修改的时候拿出来迭代一下，同时因为有图，你还可以更好的给项目成员进行宣讲。

产品中设计的流程图主要有三种，业务流程图、任务流程图、页面流程图，下面我们来一一介绍。

业务流程图

业务流程图又称为泳道图，就是描述那些个体在什么条件下做了什么事情，他们之间有何关联。主要分三个方面：

1. 涉及到哪些主体？

2. 每个主体都有哪些任务？

3. 各个主体之间怎么联系的？一般涉及到多个主体，每个主体之间有联系。

任务流程图

泳道图一般是从战略上分析整个业务流程，让你对公司所做的业务有个大概的了解，而任务流程图就是在你的产品操作上，用户通过什么样的操作来完成它的目标，比如你去银行ATM机器上取钱，你是如何一步步操作把钱取出来的。

页面流程图

如果说业务流程图帮助你梳理战略，任务流程图帮助你梳理用户操作行为（主要给程序员看）、页面跳转流程在帮助你梳理各个页面之间的跳转关系（主要给UI和前端程序员看）这是一个逐步从整体到局部，从后端到前端的过程。

 

所有的产品都是由页面组成的，不论是APP、PC、H5都是由一个个页面组成的，页面流程图描述完成一个任务需要经过哪些步骤，你在画图的时候只需要清晰的表现出用户点击页面的什么地方，然后跳转到那个页面。主要由页面、行动点、连接线组成。

UI设计图标注

对于APP的页面，UI设计师会给出UI设计标注图，这样APP客户端开发人员，直接按照标注图进行页面的开发了。

 

产品设计完成后，架构师需要对产品进行软件的架构设计。包括技术的选型，模块的划分，开发人员的任务分配，工作量的评估等等…..

系统架构设计图

构架将在一次又一次迭代中不断演化、改进、精炼。

 

序列图

架构师一般在做详细设计的时候，会把程序模块之间的每一步调用过程很详细的画出来，这样开发人员拿到设计文档，就能直接开发。

类图

 

设计图有很多种，还包括用例图，状态图，活动图…… 不再一一介绍。画什么样的设计图，不是绝对的，不同公司，不同项目，需要画的设计图也是不同的，有些项目需要画原型图，有些项目只是对外提供服务，没有页面也就不需要画原型图。另外还要根据项目的工期，预算等等因素考虑。如果一个项目的工期也就一个月甚至更短，那基本上就是怎么简单怎么快就怎么做。

画图工具

‘工欲善其事,必先利其器’，下面就为大家介绍几款常用设计图绘制工具。以下软件都可以在微信公众号，回复“设计”，获取破解版本。

Visio

是微软推出的一款流程图绘制工具，它有很多组件库，可以方便快捷的完成流程图、泳道图、结构图的绘制，但是不支持mac电脑。

 

OmniGraffle

Mac下没有Visio很多人就用这个，这个一般流程图都能绘制，但是效率感觉没有Visio高，优点就是画出来的图形比较美，同时支持外部插件，缺点就是没有比较好的泳道流程图插件，画起泳道图来不是太方便，但也可以画，可以自己组装泳道。

另外一个缺点是收费的，只能免费试用15天，不过我已经为大家准备好了一个最新的破解版本。

 

ProcessOn

是一款网页版的在线作图工具，优点是无需下载安装、破解这些破事，同时支持在线协作，可以多人同时对一个文件协作编辑，而且上手比较容易，它提供很多流程图模版，可以方便的画出流程图、思维导图、原型图、UML图，缺点就是在绘制泳道图需要增加泳道的时候，只能在最后一列加入，不能在中间加入这一点有点麻烦，还有要吐槽的就是由于是在线的，有时候导出图片，导出来的并不太好，流程图画的大的时候也无法截图。

在线地址：https://www.processon.com

 

Axure RP

这是一款产品经理经常用来画原型的工具，它可以在页面里定义各种按钮点击事件，进行页面的跳转，模拟提交的过程，所以非常方便使用。画人物流程图的时候也可以用，但是要画泳道图、UML图的时候，没有对应的模版，需要自己画，效率不高，如果你觉得画原型，制作文档都在Axure里，不想来回切换软件的画，可以在里面自己制作一个组件，下次直接调用。

Axure RP是可以画出这样效果的原型图

 

PxCook

一款还不错的标注工具.

优点：

1. 成熟：跨平台——支持Windows和Mac

2. 成熟2：支持PS和Sketch。

3. 交互特别智能，也方便，一拖一放就标注完了。

4. 相当需要说的一点：对于PSD文件或者Sketch进行了修改之后，PxCook里的标注会自动进行更新，免除了手动操作的过程。这是后面很多软件没有的。

5. 支持移动设备的多单位切换。

缺点：

1. 不能支持多个文件同时进行标注。

2. 对于图层样式等信息，不能进行详细查看。

​

iThoughtsX

一款优秀的思维导图工具

 

OmniPlan

最NB的项目管理流程软件，OmniPlan旨在帮助您可视化，维护和简化您的项目。分解任务，优化所需的资源，控制成本，并监控您的整个计划，都一目了然。协作与您的同事和分享每一个细节，更新日历与你的天关，或混搭。接受和拒绝一次过改变一个接一个或所有。

OmniPlan提供了像甘特图，时间表，摘要，里程碑和关键路径的功能突出显示，让您管理您的所有活动。从自定义的视图来快速输入数据， OmniPlan帮助您管理，因为你需要他们，简单或复杂的项目是 – 不需要复杂。

 

以上软件都可以在微信公众号，回复“设计”，获取破解版本。

 

推荐阅读：

技术：HTTP状态码大全

技术：SpringBoot 如何在一分钟内整合SSM？

技术：CentOS7下Nginx服务器安装与使用教程

技术：Java9逆天的十大新特性

技术：http2.0的时代真的来了…

工具：如何通过技术手段 “干掉” 视频APP里讨厌的广告？

工具：通过技术手段 “干掉” 视频APP里讨厌的广告之（腾讯视频）

工具：抓包神器之Charles，常用功能都在这里了

干货分享：

分享：1T 软件开发视频资源分享

分享：深度机器学习56G视频资源分享

from:http://qkljs.iteye.com/blog/2412227