1. tcp-server状态上报
get-tcp-ip接口怎么知道tcp-server集群中各台服务器是否可用呢，tcp-server主动上报是一个潜在方案，如果某一个tcp-server挂了，则会终止上报，对于停止上报状态的tcp-server，get-tcp-ip接口，将不返回给client相应的tcp-server的外网IP。
该设计的存在的问题？
诚然，状态上报解决了tcp-server高可用的问题，但这个设计犯了一个“反向依赖”的耦合小错误：使得tcp-server要依赖于一个与本身业务无关的web-server。
2. tcp-server状态拉取
更优的方案是：web-server通过“拉”的方式获取各个tcp-server的状态，而不是tcp-server通过“推”的方式上报自己的状态。
这样的话，每个tcp-server都独立与解耦，只需专注于资深的tcp业务功能即可。
高可用、负载均衡、扩展性等任务由get-tcp-ip的web-server专注来执行。
3. 多说一句，将负载均衡实现在服务端，还有一个好处，可以实现异构tcp-server的负载均衡，以及过载保护：静态实施：web-server下的多个tcp-server的IP可以配置负载权重，根据tcp-server的机器配置分配负载（nginx也有类似的功能）
动态实施：web-server可以根据“拉”回来的tcp-server的状态，动态分配负载，并在tcp-server性能极具下降时实施过载保护
4. 很多时候，业务需要跨公网调用一个第三方服务提供的接口，为了避免每个调用方都依赖于第三方服务，往往会抽象一个服务：解除调用方与第三方接口的耦合
当第三方的接口变动时，只有服务需要修改，而不是所有调用方均修改
问题：内部服务可能对上游业务提供了很多服务接口，当有一个接口跨公网第三方调用超时时，可能导致所有接口都不可用，即使大部分接口不依赖于跨公网第三方调用。
为什么会出现这种情况呢？
内部服务对业务方提供的N个接口，会共用服务容器内的工作线程（假设有100个工作线程）。
假设这N个接口的某个接口跨公网依赖于第三方的接口，发生了网络抖动，或者接口超时（不妨设超时时间为5秒）。
潜台词是，这个工作线程会被占用5秒钟，然后超时返回业务调用方。
假设这个请求的吞吐量为20qps，言下之意，很短的时间内，所有的100个工作线程都会被卡在这个第三方超时等待上，而其他N-1个原本没有问题的接口，也得不到工作线程处理。
潜在优化方案:
增大工作线程数（不根本解决问题）
降低超时时间（不根本解决问题）
垂直拆分，N个接口拆分成若干个服务，使得在出问题时，被牵连的接口尽可能少（依旧不根本解决问题，难道一个服务只提供一个接口吗？）
5. 跨公网调用第三方，可能存在的问题：公网抖动，第三方服务不稳定，影响自身服务
一个接口超时，占住工作线程，影响其他接口
降低影响的优化方案：
增大工作线程数
降低超时时间
服务垂直拆分
业务需求决定技术方案，结合业务的解决方案：
业务能接受旧数据：读取本地数据，异步代理定期更新数据
有多个第三方服务提供商：多个第三方互备
向第三方同步数据：本地写成功就算成功，异步向第三方同步数据
6. 架构设计时，能够巧用dns做一些什么事情:
1). 反向代理水平扩展:在dns-server对于同一个域名可以配置多个nginx的外网ip，每次dns解析请求，轮询返回不同的ip，这样就能实现nginx的水平扩展，这个方法叫“dns轮询”。
2). web-server负载均衡:
既然“dns轮询”可以将同一个域名的流量均匀分配到不同的nginx，那么也可以利用它来做web-server的负载均衡：
(1)架构中去掉nginx层
(2)将多个web-server的内网ip直接改为外网ip
(3)在dns-server将域名对应的外网ip进行轮询解析
和nginx相比，dns来实施负载均衡有什么优缺点呢？
优点：
利用第三方dns实施，服务端架构不用动
少了一层网络请求
不足：
dns只具备解析功能，不能保证对应外网ip的可用性（即使能够做80口的探测，实时性肯定也是比nginx差很多的），而nginx做反向代理时，与web-server之间有保活探测机制，当web-server挂掉时，能够自动迁移流量
当web-server需要扩容时，通过dns扩容生效时间长，而nginx是服务端完全自己可控的部分，web-server扩容更实时更方便
因为上面两个原因，架构上很少取消反向代理层，而直接使用dns来实施负载均衡。
3).用户就近访问:
http请求的第一个步骤域名到外网ip的转换，发生在整个服务端外部，服务端不可控，那么如果要实施“根据客户端ip来分配最近的服务器机房访问”，就只能在dns-server上做了：
(1)电信用户想要访问某一个服务器资源
(2)浏览器向dns-server发起服务器域名解析请求
(3)dns-server识别出访问者是电信用户
(4)dns-server将电信机房的nginx外网ip返回给访问者
(5)访问者就近访问
根据用户ip来返回最近的服务器ip，称为“智能dns”，cdn以及多机房多活中最常用。
总结,架构设计中，dns有它独特的功能和作用：
1).dns轮询，水平扩展反向代理层
2).去掉反向代理层，利用dns实施负载均衡
3).智能dns，根据用户ip来就近访问服务器
7. 负载均衡：
1).做两台nginx组成一个集群，分别部署上keepalived，设置成相同的虚IP，保证nginx的高可用;当一台nginx挂了，keepalived能够探测到，并将流量自动迁移到另一台nginx上，整个过程对调用方透明
优点：1）解决了高可用的问题
缺点：1）资源利用率只有50%
2）nginx仍然是接入单点，如果接入吞吐量超过的nginx的性能上限怎么办，例如qps达到了50000咧
2).nginx毕竟是软件，性能比tomcat好，但总有个上限，超出了上限，还是扛不住。lvs就不一样了，它实施在操作系统层面；f5的性能又更好了，它实施在硬件层面；它们性能比nginx好很多，例如每秒可以抗10w，这样可以利用他们来扩容
99.9999%的公司到这一步基本就能解决接入层高可用、扩展性、负载均衡的问题。
这就完美了嘛？还有潜在问题么？
好吧，不管是使用lvs还是f5，这些都是scale up的方案，根本上，lvs/f5还是会有性能上限，假设每秒能处理10w的请求，一天也只能处理80亿的请求（10w秒吞吐量*8w秒），那万一系统的日PV超过80亿怎么办呢？（好吧，没几个公司要考虑这个问题）
3).如之前文章所述，水平扩展，才是解决性能问题的根本方案，能够通过加机器扩充性能的方案才具备最好的扩展性。
facebook，google，baidu的PV是不是超过80亿呢，它们的域名只对应一个ip么，终点又是起点，还是得通过DNS轮询来进行扩容：
此时：
1）通过DNS轮询来线性扩展入口lvs层的性能
2）通过keepalived来保证高可用
3）通过lvs来扩展多个nginx
4）通过nginx来做负载均衡，业务七层路由
8. 信息安全：
1).黑客定理一：网络上传递的数据是不安全的，属于黑客公共场所，能被截取
2).黑客定理二：客户端的代码是不安全的，属于黑客本地范畴，能被逆向工程，任何客户端与服务端提前约定好的算法与密钥都是不安全的
3).黑客定理三：用户客户端内存是安全的，属于黑客远端范畴，不能被破解。（使用“具备用户特性的东西(如密码散列)”作为加密密钥，一人一密，是安全的。只是，当“具备用户特性的东西”泄漏，就有潜在风险。)
4).对于不同加密方法明：
明文消息传递如同裸奔，不安全
客户端和服务端提前约定加密算法和密钥，不安全（好多公司都是这么实现的=_=）
服务端随机生成密钥，发送给客户端，不安全
一人一密，客户端使用“具备用户特性的东西”作为加密密钥，弱安全
一次一密，三次握手建立安全信道，安全
5). 特点：每次通信前，进行密钥协商，一次一密
密钥协商过程，如下图所述，需要随机生成三次密钥，两次非对称加密密钥（公钥，私钥），一次对称加密密钥，简称安全信道建立的“三次握手”，在客户端发起安全信道建立请求后：
服务端随机生成公私钥对(公钥pk1，私钥pk2)，并将公钥pk1传给客户端 (注意：此时黑客能截获pk1)
客户端随机生成公私钥对(公钥pk11，私钥pk22)，并将公钥pk22，通过pk1加密，传给服务端 (注意：此时黑客能截获密文，也知道是通过pk1加密的，但由于黑客不知道私钥pk2，是无法解密的)
服务端收到密文，用私钥pk2解密，得到pk11
服务端随机生成对称加密密钥key=X，用pk11加密，传给客户端(注意：同理，黑客由密文无法解密出key)
客户端收到密文，用私钥pk22解密，可到key=X
至此，安全信道建立完毕，后续通讯用key=X加密，以保证信息的安全性
9. 通过上面的分析，Worker线程在执行的过程中，有一部计算时间需要占用CPU，另一部分等待时间不需要占用CPU，通过量化分析，例如打日志进行统计，可以统计出整个Worker线程执行过程中这两部分时间的比例，例如：
执行计算，占用CPU的时间（粉色时间轴）是100ms
等待时间，不占用CPU的时间（橙色时间轴）也是100ms
得到的结果是，这个线程计算和等待的时间是1：1，即有50%的时间在计算（占用CPU），50%的时间在等待（不占用CPU）：
假设此时是单核，则设置为2个工作线程就可以把CPU充分利用起来，让CPU跑到100%
假设此时是N核，则设置为2N个工作现场就可以把CPU充分利用起来，让CPU跑到N*100%
结论：
N核服务器，通过执行业务的单线程分析出本地计算时间为x，等待时间为y，则工作线程数（线程池线程数）设置为 N*(x+y)/x，能让CPU的利用率最大化。
经验：
一般来说，非CPU密集型的业务（加解密、压缩解压缩、搜索排序等业务是CPU密集型的业务），瓶颈都在后端数据库访问或者RPC调用，本地CPU计算的时间很少，所以设置几十或者几百个工作线程是能够提升吞吐量的。
10. 总结
1).线程数不是越多越好
2).sleep()不占用CPU
3).单核设置多线程不但能使得代码清晰，还能提高吞吐量
4).站点和服务最常用的线程模型是“IO线程与工作现场通过任务队列解耦”，此时设置多工作线程可以提升吞吐量
5).N核服务器，通过日志分析出任务执行过程中，本地计算时间为x，等待时间为y，则工作线程数（线程池线程数）设置为 N*(x+y)/x，能让CPU的利用率最大化
11. 不止sleep()函数，在进行一些阻塞调用时，例如网络编程中的：阻塞accept()，等待客户端连接; 阻塞recv()，等待下游回包; 都不占用CPU资源。
12. 业务有定时任务或者定时超时的需求，当任务量很大时，可能需要维护大量的timer，或者进行低效的扫描。
1).“轮询扫描法”
a.用一个Map<uid, last_packet_time>来记录每一个uid最近一次请求时间last_packet_time
b.当某个用户uid有请求包来到，实时更新这个Map
c.启动一个timer，当Map中不为空时，轮询扫描这个Map，看每个uid的last_packet_time是否超过30s，如果超过则进行超时处理
问题：只启动一个timer，但需要轮询，效率较低
2).“多timer触发法”
a.用一个Map<uid, last_packet_time>来记录每一个uid最近一次请求时间last_packet_time
b.当某个用户uid有请求包来到，实时更新这个Map，并同时对这个uid请求包启动一个timer，30s之后触发
c.每个uid请求包对应的timer触发后，看Map中，查看这个uid的last_packet_time是否超过30s，如果超过则进行超时处理
问题：不需要轮询，但每个请求包要启动一个timer，比较耗资源
3).环形队列法:
三个重要的数据结构：
1）30s超时，就创建一个index从0到30的环形队列（本质是个数组）
2）环上每一个slot是一个Set<uid>，任务集合
3）同时还有一个Map<uid, index>，记录uid落在环上的哪个slot里
同时：
1）启动一个timer，每隔1s，在上述环形队列中移动一格，0->1->2->3…->29->30->0…
2）有一个Current Index指针来标识刚检测过的slot
当有某用户uid有请求包到达时：
1）从Map结构中，查找出这个uid存储在哪一个slot里
2）从这个slot的Set结构中，删除这个uid
3）将uid重新加入到新的slot中，具体是哪一个slot呢 => Current Index指针所指向的上一个slot，因为这个slot，会被timer在30s之后扫描到
4）更新Map，这个uid对应slot的index值
哪些元素会被超时掉呢？
Current Index每秒种移动一个slot，这个slot对应的Set<uid>中所有uid都应该被集体超时！如果最近30s有请求包来到，一定被放到Current Index的前一个slot了，Current Index所在的slot对应Set中所有元素，都是最近30s没有请求包来到的。
所以，当没有超时时，Current Index扫到的每一个slot的Set中应该都没有元素。
优势：
（1）只需要1个timer
（2）timer每1s只需要一次触发，消耗CPU很低
（3）批量超时，Current Index扫到的slot，Set中所有元素都应该被超时掉
这个环形队列法是一个通用的方法，Set和Map中可以是任何task，本文的uid是一个最简单的举例。
HashedWheelTimer也是类似的原理，有兴趣的同学可以百度一下这个数据结构，Netty中的一个工具类
13. URI设计原则
1). URI的末尾不要添加“/”
多一个斜杠，语义完全不同，究竟是目录，还是资源，还是不确定而多做一次301跳转？
负面case：http://api.canvas.com/shapes/
正面case：http://api.canvas.com/shapes
2).使用“-”提高URI的可读性
目的是使得URI便于理解，用“-”来连接单词
正面case：http://api.example.com/blogs/my-first-post
3).禁止在URL中使用“_”
目的是提高可读性，“_”可能被文本查看器中的下划线特效遮蔽
负面case：http://api.example.com/blogs/my_first_post
别争，看到效果就明白了
4).禁止使用大写字母
RFC 3986中规定URI区分大小写，但别用大写字母来为难程序员了，既不美观，又麻烦
负面case：http://api.example.com/My-Folder/My-Doc
正面case：http://api.example.com/my-folder/my-doc
5).不要在URI中包含扩展名
应鼓励REST API客户端使用HTTP提供的格式选择机制Accept request header
正面case：http://58.com/bj/ershou/310976
一个case：http://58.com/bj/ershou/310976x.shtml
6).建议URI中的名称使用复数
额，楼主不知道为何会有这么奇怪的建议
正面case：http://api.college.com/students/3248234/courses
负面case：http://api.college.com/student/3248234/course