@ylxb23 哈哈哈哈

@boywhp 嗯，Go 带来了开发效率，自然就是牺牲了一部分运行效率。不过我认为仅仅达到 Nginx 的一半是不够的。
还是有很多地方可以优化的。

Go 一个周末可以搞定熔断的大部分功能，用 C 从头来不知道要多久呢

@sophos 存在这种可能性。因为没有足够强大的机器来开多虚拟机测试。只在自己的笔记本上做了简单地测试。

另外 @janxin README 已经更新了。刚才把随机和朴素的轮询实现了

@sophos 是的。其实目前性能瓶颈在于 `net.http` 里自带的 proxy。创建了太多的对象。其他的地方性能虽然还可以优化，但是对整体提升不是特别大。

另外关于稳定性方面，从测试来看，Go 的 proxy 稳定性似乎好于 Nginx 哟

@janxin 目前还只实现了 weighted round robin。random 和普通的 round robin 还没做呢，昨天忙着分析瓶颈去了。如果有兴趣的话，可以提个 PR :)

@Mitt 😋

欢迎大家一起完善💪

@takato wow, thanks

@cloudzhou 有用 pprof 分析的，虽然 topN 最前面的是 runtime 里的例如 defer，我自己写的代码里比较靠前的就是锁的相关操作了。统计这块应该可以用 channel 改造

@paw
@WuwuGin
@secondwtq
@cloudzhou
Go 语言，统计部分是指统计过去一段时间的响应码，用这份统计数据来决定新的请求是否需要熔断，所以需要确保准确。

@liprais 是的，因为目前最熟悉的是 MySQL ～

我是工程师~

万科内部有买房优惠~我们还有深圳的人才公寓~欢迎加入

2018 年我们准备做的事情有：

- 分布式环境中请求追踪（分布式系统）
- OAuth 微服务（流量入口级别，高并发）
- 熔断器（流量入口级别，高并发）
- 攻击主动发现以及防御（机器学习）
- 自动化运维
- 以及最最最最最重要的，单体服务拆分
- ....(其他的来了再告诉你)

@CarpeDiemmm 哈哈~

@jingniao 是的，但是这种比较正式的说法，最开始接触的人往往不得其解

@WeaPoon :joy: 你所的对
@NonClockworkChen 短的都被注册了
@ztshia 哈哈哈，.com 域名不是大众认可度比较高嘛
@qiuai 嗯，也许可以用来搞点啥

除了上面提到的，还想到一些：

- 自动化部署
- 阅读开源代码，学习别人家的软件是怎么设计的。Nginx ？ Redis ？也许你不写 c 可能突然读这些难度太大对于当下的工作益处也不是能显现的。自己去挖掘自己所用语言的框架啊，非常出名的软件啊等等的开源代码去阅读。
- 阅读文档，很多大型软件的源代码已经不是一下子能搞清楚的了。而常用的大型软件的配置你未来肯定会用到，比如 Nginx 的配置，比如 Redis 的命令。

想不出了。。都是临时想的。你可以对着这些一个一个慢慢来掌握。

或者有其他疑问，可以邮件交流。 我想想交流的人能找到邮件是多少的 :)

最开始是这样的。正式工作大部分时间也是这样的。在没有一定量级之前都是这样的（在毫无并发量可言的环境下，API 如何如何都体现不出来）。但是量级来了之后，事情就开始变得不同了。

- 数据库优化（检查数据库 model 设计是否合理-查看检索语句是否用到了索引-升级数据库配置-“三星”索引优化-垂直分表-水平分表-垂直分库-水平分库(shard)）
- 缓存(中心化缓存 /去中心化缓存)
- 负载均衡（ Nginx 可以作为后端应用服务器的负载均衡器从而避免后端应用服务作为单点，那谁又可以作为 Nginx 的负载均衡呢？原理是什么？）
- 异步任务（选取何种 MQ ？ Redis 是否足够？是否需要消费确认？异步任务框架的工作原理？）
- ...

还有很多很多很多知识我猜你可能是不知道的。

@admirez 第一是用 redis 的都会, 第二是并不是所有任务都需要 100%不丢, 而且丢任务是指,从 redis 拿出任务之后,如果任务队列挂了,那么 redis 是不知道的. 如果 redis 像 rabbitmq 一样提供消费确认, 就没有这种事情了

来一个