netflix

以往我们说起来编码效率优化，都是想得如何去优化编码器里面的算法，但是netflix的一些做法给了我们新的启示，也许不用费劲去研究编码算法，只是改变一下编码器的用法，一样能获得更高的编码效率，节省更多的带宽。 一、Per-Tiitle Encoding 2015年的时候，netflix推出了per titile encoding方案，简单来说就是依据每个视频的特性，比如时间复杂度和空间复杂度，来决定服务端编码的码率级别，不同于以往给所有视频统一码率级别的编码方式，这种方法可以更好的平衡质量和带宽。 很显然，对于小猪佩奇这样的动画片，画面简单，没有复杂的运动，我们可以用很少的码率达到很高的质量，但是对于复仇者联盟这样的电影，打斗场面丰富，就需要相应的稍高的码率了。 netflix没有专门去研究时间复杂度，空间复杂度，码率与主观质量之间的关系，而是采用了一种更加简单粗暴的方法，如下图。将一个片源按照不同分辨率码率组合进行编码，计算psnr值，画出r-d曲线图 图中红色曲线是r-d曲线的凸包，对于每个分辨率的曲线，最接近凸包的点即为编码效率最好的点，这些点就选为最终的分辨率-码率参数。 效果如何呢？参考下图 这是对一个普通电影的优化效果，这部电影的复杂度适中，中间的黄色栏是采用固定码率级别时的情况，右边表格的绿色部分分别展示了使用per title

SpringCloud（十六）Eureka Client启动后就关闭 Unregistering application xxx with eureka with status DOWN springboot版本： 2.0.1.RELEASE springcloud版本： Finchley.RELEASE 日志： 2018-07-15 10:50:10.516 INFO 16952 --- [ main] c.x.springcloud.EurekaClientApplication : Started EurekaClientApplication in 8.884 seconds (JVM running for 10.459) 2018-07-15 10:50:10.522 INFO 16952 --- [ Thread-23] s.c.a.AnnotationConfigApplicationContext : Closing org.springframework.context.annotation.AnnotationConfigApplicationContext@4278284b: startup date [Sun Jul 15 10:50:05 CST 2018]; parent: org.springframework.context.annotation

eureka : client : service - url : defaultZone : http : //127.0.0.1:19003/eureka/ 如果这样配置还是注册不上就换版本吧，从2降到1. 来源：博客园 作者： goblinn 链接：https://www.cnblogs.com/goblinn/p/11435605.html

boot和cloud对应的版本号不能搞混，对应版本请参考 https://spring.io/projects/spring-cloud#overview The bean 'eurekaRegistration', defined in class path resource [org/springframework/cloud/netflix/eureka/EurekaClientAutoConfiguration$EurekaClientConfiguration.class], could not be registered. A bean with that name has already been defined in class path resource [org/springframework/cloud/netflix/eureka/EurekaClientAutoConfiguration$RefreshableEurekaClientConfiguration.class] and overriding is disabled. "C:\Program Files\Java\jdk1.8.0_192\bin\java.exe" -javaagent:D:\DevProFiles\ideaIU-2018.2.8\lib\idea_rt.jar=63000:D

版权声明：本文为博主原创文章，转载标注出处。联系微信btc20002000 https://blog.csdn.net/qq_36666115/article/details/90510633 Netflix（官方中文名：网飞）是一间在世界多国提供网路视频点播的OTT服务公司[7]，并同时在美国经营单一费率邮寄DVD出租服务。该服务是使用回邮信封寄送DVD和Blu-ray出租光碟片至消费者指定的收件地址。公司由里德・哈斯廷斯和马尔克・兰多夫在1997年8月29日成立，总部位于加利福尼亚州洛斯盖图，1999年开始推出订阅制的服务。到了2009年，Netflix已可提供超过10万部电影DVD，订阅者数超过1000万人[8]。 网盘下载地址： http://t.cn/E9H4meP 文章来源: https://blog.csdn.net/qq_36666115/article/details/90510633

参考： https://blog.csdn.net/u014091123/article/details/75433656 https://blog.csdn.net/u013815546/article/details/68944039 Zuul是Netflix开源的微服务网关，他的核心是一系列的过滤器，通过这些过滤器我们可以轻松的实现服务的访问认证、限流、路由、负载、熔断等功能。 基于对已有项目代码零侵入的需求，本文没有将zuul网关项目注册到eureka中心，而是将zuul与springboot结合作为一个独立的项目进行请求转发，因此本项目是非spring cloud架构。 pom.xml 1 <dependency> 2 <groupId>org.springframework.cloud</groupId> 3 <artifactId>spring-cloud-starter-zuul</artifactId> 4 <version>1.4.4.RELEASE</version> 5 </dependency> application.properties 1 server.port=8090 2 eureka.client.enable=false 3 zuul.ribbon.eager-load.enabled=true 4 5 zuul

微服务 网关服务 网关服务是微服务体系里面重要的一环。 微服务体系内，各个服务之间都会有通用的功能比如说：鉴权、安全、监控、日志、服务调度转发。这些都是可以单独抽象出来做一个服务来处理。所以微服务网关应运而生。其主要作用作为微服务体系里面流量的唯一入口去做一些功能的实现。 微服务的网关担当的主要职责可以分为俩种 主要业务功能抽取，鉴权、安全、服务调度、限流、熔断等 非主要的业务功能抽取，监控、日志、缓存、黑白名单、埋点等 Spring Cloud 网关服务 现在市面主要流行的俩种 Netflix Zuul 1.0 由Netflix开源的API网关项目，这个服务并不是Netflix 集成到spring 微服务体系内。而是spring将zuul集成在spring-cloud中使用而已。目前spring不打算集成zuul2.x的集成。 Spring Cloud Gataway spring-cloud-Gateway是spring旗下spring-cloud的一个子项目。还有一种说法是因为zuul2连续跳票和zuul1的性能表现不是很理想，所以催生了spring孵化Gateway项目。 前面介绍了俩种网关服务由来，接下来进行一下性能的对比我不打算在做压力测试方向更多的介绍，博主没有做压力测试的条件。我讲推荐一篇博文进行了压测的详细的对比 传送门 Spring Cloud Gateway

原文链接： http://www.infoworld.com/article/2925047/application-development/build-self-healing-distributed-systems-with-spring-cloud.html 这篇文章介绍了如何 Spring Cloud 是如何帮助构建一个高可用的分布式系统的。在同类文章算是介绍的很不错的，感觉比 Spring Blog 里面的文章还要更全面易懂。 文章开始先介绍了构建分布式系统时会遇到的各种需要解决的问题，然后分别由这些问题引出 Spring Cloud 中的各种技术。 Spring Cloud Config Server Spring Cloud Config Server 以 Git、SVN 等 VCS 系统存储 properties、yml 等格式的配置文件，构建了一个可横向伸缩的配置服务器。且不说使用效果怎么样，这个思想还是很有启发性的。配置文件通常是文本文件，用 VCS 存储是顺理成章的，同时还具备了版本控制功能，使得配置的变化被记录了下来。再在这个基础之上，加上横向伸缩的能力，便成为了一个很不错的配置服务器。 Spring Cloud Bus Spring Cloud Bus 为 Spring 应用提供了 Message Broker 的功能。目前的唯一实现是基于 AMQP 的

实际业务中，如果要自定义filter过滤器，只需集成ZuulFIlter类即可，该类是个抽象类，它实现了IZuulFIlter接口，我们需要实现几个方法，如下示例： import static org.springframework.cloud.netflix.zuul.filters.support.FilterConstants.PRE_TYPE; import javax.servlet.http.HttpServletRequest; import com.netflix.zuul.ZuulFilter; import com.netflix.zuul.context.RequestContext; import com.netflix.zuul.exception.ZuulException; public class ThirdPreFilter extends ZuulFilter { /** * 设置filter的类型，支持4种类型 * {@link org.springframework.cloud.netflix.zuul.filters.support.FilterConstants} * <pre> * ERROR_TYPE = "error";//这种过滤器是在整个生命周期内，如果发生异常，就执行该filter，可以做全局异常处理。 * POST_TYPE

Spring Cloud Netflix常用组件 服务注册与发现：Eureka 服务负载均衡： Ribbon 服务声明式客户端： Feign 服务熔断：Hystrix 服务网关 : Zuul Eureka: Eureka分客户端client和服务端server。各微服务为client,将自己的信息注册到server。 微服务启动后(默认每隔30秒)，client做2件事：1. 拉取最新注册服务信息。2. 向server发送心跳，告诉server自己没有挂。 如果server在一定时间（默认90秒）内没有收到某个微服务节点的心跳，server将会注销该微服务节点。 每个Eureka Server同时也是Eureka Client，多个Eureka Server之间通过复制的方式完成服务注册表的同步。 server存储客户端端口号，IP地址等。 Q:作为服务中心Eureka比ZooKeeper好在哪里? 参考《阿里巴巴为什么不用 ZooKeeper 做服务发现？》 在分布式的CAP理论中，ZK保证CP, Eureka保证AP。向服务中心查询服务时，可以容忍返回的时几分钟之前的注册信息，但不能接收服务挂掉不可用。 ZK多机房会出现网络孤岛，导致本机房的服务B不能新部署，重启，扩容或缩容。本机房的服务A则不能调用服务B。破坏服务之间本身的可连通性，违反注册中心的原则！