wrk

15 位青春洋溢的女团候选成员，百万次全网观众投票，节目播出后迅速霸占热搜前十位..... 在这激动人心的决赛之夜，Tencent Serverless 团队下的云 API 网关产品作为幕后英雄，利用其高并发、高可用的技术特性，支撑了节目投票环节顺利开展，面对全网粉丝狂热打 call 投票，顺利保障小姐姐们 C 位出道！ 不一般的投票 【投票】是一个很简单的功能，但是《创造营》的投票不一样。 《创造营》是直播节目，投票时间非常短。海量全网粉丝将在同一时间瞬时涌入，瞬间的大流量和高并发，对系统的高可用性提出了极高的要求。 《创造营》投票，将产生本届总冠军，是《创造营》决胜之夜的制胜环节，激动人心的时刻。投票系统的任何差池，都会对粉丝心理和节目效果造成重创。 在投票的关键时刻，为了保证女团小姐姐顺利出道，技术小哥哥采用了什么样的技术设计，保证了这种特殊场景下的投票功能高可用呢？ Serverless Serverless 是一种云计算技术的新趋势，一方面它使开发者在构建和运行应用时无需管理服务器等基础设施，将构建应用的成本进一步降低，实现快速迭代、极速部署；同时，Serverless尤其适用于高并发场景，无需预估流量大小，而会根据流量情况自动的进行扩缩容，整个过程无需人工干预；值得一提的是，Serverless 还是按用量付费的模式，避免了无用的资源开销，大大降低了成本。

GO性能分析 Go语言内置了获取程序运行数据的工具，包括以下两个标准库： runtime/pprof: 采集工具型应用运行数据进行分析 net/http/pprof: 采集服务型应用运行时数据进行分析 pprof是什么？ pprof 是用于可视化和分析性能分析数据的工具 pprof 以 profile.proto 读取分析样本的集合，并生成报告以可视化并帮助分析数据（支持文本和图形报告） profile.proto 是一个 Protocol Buffer v3 的描述文件，它描述了一组 callstack 和 symbolization 信息， 作用是表示统计分析的一组采样的调用栈，是很常见的 stacktrace 配置文件格式 支持什么使用模式 Report generation：报告生成 Interactive terminal use：交互式终端使用 Web interface：Web 界面 可以做什么？ CPU Profiling：CPU 分析，按照一定的频率采集所监听的应用程序 CPU（含寄存器）的使用情况，可确定应用程序在主动消耗 CPU 周期时花费时间的位置 Memory Profiling：内存分析，在应用程序进行堆分配时记录堆栈跟踪，用于监视当前和历史内存使用情况，以及检查内存泄漏 Block Profiling：阻塞分析，记录 goroutine 阻塞等待同步

15 位青春洋溢的女团候选成员，百万次全网观众投票，节目播出后迅速霸占热搜前十位..... 在这激动人心的决赛之夜，Tencent Serverless 团队下的云 API 网关产品作为幕后英雄，利用其高并发、高可用的技术特性，支撑了节目投票环节顺利开展，面对全网粉丝狂热打 call 投票，顺利保障小姐姐们 C 位出道！ 不一般的投票 【投票】是一个很简单的功能，但是《创造营》的投票不一样。 《创造营》是直播节目，投票时间非常短。海量全网粉丝将在同一时间瞬时涌入，瞬间的大流量和高并发，对系统的高可用性提出了极高的要求。 《创造营》投票，将产生本届总冠军，是《创造营》决胜之夜的制胜环节，激动人心的时刻。投票系统的任何差池，都会对粉丝心理和节目效果造成重创。 在投票的关键时刻，为了保证女团小姐姐顺利出道，技术小哥哥采用了什么样的技术设计，保证了这种特殊场景下的投票功能高可用呢？ Serverless Serverless 是一种云计算技术的新趋势，一方面它使开发者在构建和运行应用时无需管理服务器等基础设施，将构建应用的成本进一步降低，实现快速迭代、极速部署；同时，Serverless尤其适用于高并发场景，无需预估流量大小，而会根据流量情况自动的进行扩缩容，整个过程无需人工干预；值得一提的是，Serverless 还是按用量付费的模式，避免了无用的资源开销，大大降低了成本。

前言 如果你想将你开发的控件与别人分享，一种方法是直接提供源代码文件。然而，这种方法并不是很优雅。它会 暴露所有的实现细节 ，而这些实现你可能并不想开源出来。此外，开发者也可能并不想看到你的所有代码，因为他们可能仅仅希望将你的这份漂亮代码的一部分植入自己的应用中。 另一种方法是将你的代码编译成静态库（library），让其他开发者添加到自己的项目中。然而，这需要你一并公布所有的公开的头文件，实在是非常不方便。 你需要一种简单的方法来编译你的代码，这种方法应该使得你的代码易分享，并且在多个工程中易复用。你需要的是一种方法来打包你的静态库，将所有的头文件放到一个单元中，这样你就可以立刻将其加入到你的项目中并使用。 OS X完美地支持这一点，因为Xcode就提供了一个项目模板，包含着默认构建目标（target）和可以容纳类似于图片、声音、字体等资源的文件。你可以为iOS创建Framework，不过这是一个比较复杂的手工活，如果你跟着教程走，你将学到怎么样跨过路障，顺利地完成Framework的创建。 比较 可以参考这篇文章 .a和.framework .a和.framework的区别 。 我们可以看出.a的封装和.framework的封装差不多，也有模拟器和真机合并的过程，通过上边的图片我们可以看出.a 和.framework的区别，就是.a+.h+soureFile=

一、分析总结 系统是应用的运行环境，系统的瓶颈会导致应用的性能下降； 而应用的不合理设计，也会引发系统资源的瓶颈。 （1）CPU 性能分析 （2）内存性能分析 （3）磁盘和文件系统 I/O 性能分析 （4）网络性能分析 （5）应用程序瓶颈分析 1）strace，观察系统调用； 2）perf 和火焰图，分析热点函数； 3）动态追踪技术，来分析进程的执行状态。     二、优化总结 （1）CPU 优化 核心在于排除所有不必要的工作、充分利用 CPU 缓存并减少进程调度对性能的影响。 1）把进程绑定到一个或者多个 CPU 上，充分利用 CPU 缓存的本地性，并减少进程间的相互影响。 2）为中断处理程序开启多 CPU 负载均衡，以便在发生大量中断时，可以充分利用多 CPU 的优势分摊负载。 3）使用 Cgroups 等方法，为进程设置资源限制，避免个别进程消耗过多的 CPU。同时，为核心应用程序设置更高的优先级，减少低优先级任务的影响。 （2）内存优化 核心是解决内存使用的问题，如 可用内存不足、内存泄漏、Swap 过多、缺页异常过多以及缓存过多等。 1）除非有必要，Swap 应该禁止掉。这样就可以避免 Swap 的额外 I/O ，带来内存访问变慢的问题。 2）使用 Cgroups 等方法，为进程设置内存限制。这样就可以避免个别进程消耗过多内存，而影响了其他进程。对于核心应用，还应该降低

Guava中的RateLimiter可以限制单进程中某个方法的速率，本文主要介绍如何使用，实现原理请参考文档： 推荐：超详细的Guava RateLimiter限流原理解析 和 推荐：RateLimiter 源码分析(Guava 和 Sentinel 实现) 。 1 基于spring-mvc的controller测试限流 完整代码可参考： https://github.com/sxpujs/spring-cloud-examples/tree/master/rest-service 1.1 增加Maven依赖： <dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>29.0-jre</version> </dependency> 1.2 AccessLimitService 限流Service类 @Service public class AccessLimitService { // 每秒发出5个令牌 RateLimiter rateLimiter = RateLimiter.create(5.0); /** * 尝试获取令牌 */ public boolean tryAcquire() { return rateLimiter.tryAcquire();

Guava中的RateLimiter可以限制单进程中某个方法的速率，本文主要介绍如何使用，实现原理请参考文档： 推荐：超详细的Guava RateLimiter限流原理解析 和 推荐：RateLimiter 源码分析(Guava 和 Sentinel 实现) 。 1 基于spring-mvc的controller测试限流 完整代码可参考： https://github.com/sxpujs/spring-cloud-examples/tree/master/rest-service 1.1 增加Maven依赖： <dependency> <groupId>com.google.guava</groupId> <artifactId>guava</artifactId> <version>29.0-jre</version> </dependency> 1.2 AccessLimitService 限流Service类 @Service public class AccessLimitService { // 每秒发出5个令牌 RateLimiter rateLimiter = RateLimiter.create(5.0); /** * 尝试获取令牌 */ public boolean tryAcquire() { return rateLimiter.tryAcquire();

有感于 myzony 发布的 针对 Ocelot 网关的性能测试 ，并且公司下一步也需要对.net和java的应用做一定的整合，于是对Ocelot网关、Spring Cloud Gateway网关做个了对比测试，使用了wrk进行测试 .net core + Spring Cloud Gateway 是使用 steeltoe 工具接入注册中心Spring Cloud Eureka，共Spring Cloud Gateway调用 应用服务器环境 windows server 2008 .net core 2.2 java 1.8 172.16.1.65 部署 Ocelot的.net core接口-6002、Spring Cloud Gateway的spring boot接口-9004、Spring Cloud Gateway的.net core接口-9001 172.16.1.68 部署 Ocelot的.net core接口-6004、Spring Cloud Gateway的spring boot接口-9004、Spring Cloud Gateway的.net core接口-9001 172.16.1.120 部署 Ocelot网关-6000、Spring Cloud Eureka注册中心-7000 + Spring Cloud Gateway网关-8000 测试工具 wrk

1 为什么要升级为spring-cloud-gateway？ Spring Cloud Gateway features: Built on Spring Framework 5, Project Reactor and Spring Boot 2.0 Able to match routes on any request attribute. Predicates and filters are specific to routes. Hystrix Circuit Breaker integration. Spring Cloud DiscoveryClient integration Easy to write Predicates and Filters Request Rate Limiting Path Rewriting 这是官方说的，spring gateway相对spring zuul要新很多，应用也更加自由，开发体验更好。但是我在测试中发现，spring-cloud-gateway相对于zuul来说，更加出众的还是其性能，当然最后让我放弃的也是因为这一点。 网上的朋友也有做一些gateway和zuul的性能比较，大多的结论也是gateway要优于zuul，同时也更加稳定。 但是我们不能轻信，所以我也做了测试,这部分测试内容若不感兴趣可以跳过，zuul就不测试了。