Netflix 开源目的 来源
Netflix 不仅美剧拍得好，在Java的微服务（Micro Service）、云原生（Cloud Native）、混沌工程（Chaos Engineering）领域都是先行者，上图为他们的开源宗旨，吸引顶尖开发者/树立行业标准/打造技术品牌/与开源社区互惠互利，格局之大，确实值得我们学习，例如 Spring 推出的 spring cloud 就是在Netflix开源的众多微服务框架基础上扩展而来的，当然，现在Spring Cloud丰富多了。
顺手推荐几部Netflix出品，看过觉得很不错的美剧。
毒枭，豆瓣9.2，讲述墨西哥第一贩毒帝国 瓜达拉哈拉 贩毒集团的成长史，电视剧开拍前，电影制片人还被墨西哥毒贩枪杀，都无法阻挡毒枭的上映，可以跟HBO权利的游戏媲美的剧情。
纸牌屋 ，豆瓣9.3，讲述美国政界的暗黑系故事，套用里面的经典台词， 没有永远的敌人，只有永远的利益。
性爱自修室， 豆瓣评分9.1，喜剧、温馨、X教育，看名字就知道是好剧，值得探究。
扯远了，来看看Netflix 在github上开源java项目，按照star数降序排列。
Netflix /Hystrix
资源隔离以及 熔断 中间件，alibaba对等的有Sentinel，对自我系统的保护，防止整个链路雪崩，比如下图，订单调用商品，商品调用库存，当库存连接对应db出现抖动，造成库存服务rt飙升，当持续商品rpc进入，造成库存服务线程池满/cpu打满/内存大量gc，进而影响到商品服务，订单服务，整条下单链路崩溃，hystrix可以设定一定的服务阈值，超过某种情况，直接fail back到上游服务，避免整条服务链路雪崩。
不过现在官方Hystrix已经不再更新了，给出来的理由如下图，意思是说 1.5.18的Hystrix功能已能够满足Netflix目前的功能，他们把注意力转向实时的系统限流配置而不是预先的阈值设定，比如下面要提到的 Netflix/concurrency-limits，链接—-
Netflix/zuul
netflix zuul
java层的服务网关，类似于前置的 nginx ，功能更丰富，如 鉴权 、过滤、路由转发，通常与 eureka +ribbon联合使用，spring cloud套装里面都支持。，链接—-
Netflix/eureka
用于服务注册与服务发现，alibaba对等的有nacos，服务提供者启动时将服务提供者元信息注册到eureka server上，服务消费者通过eureka client连接eureka server获取服务提供者元信息，进而通过http请求访问服务提供者，完成数据交换。链接—-
Netflix/SimianArmy
猴子军团，对于小公司，估计用不到，这个属于混沌工程的东西，是云原生体系下提高系统弹性能力的技术方式，当整个公司服务在云上，几千上万台云机之间相互调用，会出现例如进程挂掉、依赖超时、数据库慢sql、宿主机cpu抢占、网络丢包等等不可靠的因素，如何在日常系统运行中，先行发现问题，自动痊愈，不影响客户的体验，是众多大厂不可避免的问题，例如某大厂的中美新多地部署、双机房、多可用区，自动切流容灾能力，但是还没有达到混沌工程里描述的那么牛逼。
不过此项目也不再维护了，因为相关功能都被迁移到其他项目了，有兴趣，可进一步了解。链接—-
Netflix/ribbon
软负载均衡，例如常见的简单 轮询 ，加权轮询，随机轮询，复杂的区域感知轮询等之类，例如上图 公网 流量请求，到aws的弹性负载均衡elb后，分别进入美东的两个可用区，通过ribbn的hash轮询到不同的服务提供者机器上，链接—-
Netflix/conductor
微服务编排功能，图形化的流程调度，我们在一个应用中通常会用 bpm 去做流程的编排，condutor是基于多应用、多服务依赖的流程编排，链接—-
Netflix/concurrency-limits
自适应限流工具，常见的限流框架例如hystrix/sentinel 都需要预先设定一个限流阈值，这需要对应用进行 压测 ，通常情况下，压测的环境与线上真实流量还是有些差别的，导致预先设定的阈值要么高/要么低，concurrency-limits利用tcp拥堵算法实时拟定限流阈值，高端，Netflix也是在持续更新，链接—-
Netflix/archaius
支持多数据源、动态的配置管理工具，，链接—-
Netflix/curator
zookeeper的java客户端，如今已经捐献给 apache ，curator官网很有意思的一句话如上图，链接—-
Netflix/EVCache
分布式缓存，异步复制消息，链接—-
Netflix 的美剧看得不能自拔，他们对开源的贡献以及对业界技术的引领，也是值得佩服的，这可能和他们公司的文化观有关
国内最近几年随着阿里开源的项目越来越多，大家对 github 的使用也越来越频繁，毕竟还出现过国外友人针对中文的github项目提出english-please，大致意思是说，我们的中文项目最好有英文的readme之类的，方便理解，链接—-。
当然，个人觉得，招致此种非议，一方面英文毕竟是全世界通用的语言，另一方面是不是也是我们一直关注业务场景、商业模式，无论大厂还是小厂，无论是kpi或者是okr，都是屁股决定脑袋，当开源项目数目是 kpi 时，就把老版本的内部项目开源，也不维护，这在国内还是很常见的，还是希望我们的互联网行业，底层芯片、操作系统等基础性东西，能够有所突破，不能说扬眉吐气，至少能不被别人卡脖子。
开源互联是我们的机会，大家觉得呢？如果你有好看的美剧，在评论区安利一波？
