surlymo的博客

架构师成长之路之限流文章目录架构师成长之路之限流1. 我们为什么需要限流2. 我们常见的限流手段2.1 信号量计数2.2 线程池隔离2.3 固定窗口计数2.4 自然窗口计数2.5 滑动窗口计数2.5.1 基于共享分布式内存2.5.2 基于本地内存2.6 令牌桶和漏桶算法计数3. 微服务限流几个考虑的点3.1 机器时钟不一致或者时钟回退问题3.2 在SDK还是Server端做限流逻辑3.3 限流...

基于SEDA的异步框架设计与实现 一、SEDA国内外研究现状1、SEDA架构的起源和特点    当前最流行的互联网服务器模型基本都是基于多线程／进程并发服务模型。然而当线程数目增加到一定值后，系统性能会下降，这就限制了系统支持高并发请求的能力。这种缺陷是多线程／进程本身的架构造成的。加州大学伯克利分校的Matt Welsh提出了一种新的服务器软件架构SEDA。SEDA是Staged E

基于SEDA的异步框架设计与实现   二、为什么使用SEDA        目前，面对并发环境，主流互联网服务器编程模型有两种：多线程模型以及事件驱动模型。但是这两个模型都不足以解决这个问题。我们来首先看一下这两种编程模型。 1、多线程并发模型           多线程并发模型是目前最普遍的服务器编程模型，该模型的架构如下图所示：        该模型针对每一

基于SEDA的异步框架设计与实现三、异步框架技术选型       在这次实现的SEDA异步框架中，采用的基础架构原型如下：        采用了spring+quartz+fastjson+rabbitmq来实现。和传统SEDA架构区别比较大的地方在于：        1、采用分布式mq（使用了rabbitmq）而不是blockingqueue。如此既可以支持以后可能进行的分布式化

基于SEDA的异步框架设计与实现四、异步框架总体设计与实现 1、框架中的stage理想结构       前文提到，基于SEDA的异步框架，一个stage的理想结构描述如下：             在这个框架的设想中，一个stage一般需要有如下几个组件：       1、D-MQ：分布式消息中间件。用做事件队列，以进行消息的传递。       2、Local-Queu

开篇明义：【大型网站技术架构笔记】系列是阅读《大型网站技术架构核心原理与实践》一书的一些笔记，记录了原书的一些重要内容以及我的个人理解。其中很多内容网上都能找得到。其实整本书，我最赞同的是作者阐述的网站架构的价值观——“业务成就技术，而不是相反”。在没有业务场景的时候就一味追逐架构，为技术而技术，或者一上来就想要设计出一个可以适用所有场景的解决方案，是不理智的。我们有的时候可能会陷入技术的怪圈

架构模式系统朝大型系统衍变的过程中，如下几个架构模式是我们应该考虑也终将经历的。分层即对系统进行横向划分。比如进行MVC分层，又可分为接入层、业务层、核心数据层。应当禁止跨层调用以及逆向调用。分割即对系统进行纵向划分。比如在业务层上拆解业务，核心数据层上划分不同类型的数据，以方便流量控制等。分布式分布式部署一般耳熟能详。也是SOA中重要的一环。但是在没有高效分布式事务的前提下，如何在分布式中保证数据

性能测试指标1.响应时间。 2.并发数。如果暂时没有对应的准确监控，针对不同业务模型，可以有不一样的并发数的预估。我们的系统进行峰值并发数预估的话，有一种比较粗略的计算方式，即全天请求平均每秒并发数 * 3。但也需要case by case。 3.吞吐量。比较常见的有QPS（每秒查询数）、HPS（每秒http请求数）以及TPS（每秒处理事务数）。 4.性能计数器。包括系统负载、线程数、cpu、

网站架构的伸缩性设计一般手段有两种。一类是根据功能进行物理分离，一类是对单一功能进行集群化来实现。比如将缓存、静态文件、数据库服务从服务器中拆分进行单独部署，比如对业务逻辑进行横向纵向切分等，都属于通过物理分离来达成整个系统处理能力的伸缩。对服务进行集群化这个应用场景非常广泛。此处无需再多说。应用服务器进行伸缩的方法网站进行伸缩过程中，由于采用了集群技术，所以不可避免的要面对服务集群化后的负载均衡问

前言现在市面上有非常多介绍Servicemesh概念、架构、方法论以及标准化实现的文章，但是对于Servicemesh应该如何才能被真正有效可靠的落地，我们会面临哪些困难选择，并未太多提及。本文希望从这个角度出发，结合笔者在生产环境落地中的一些经验和踩过的坑，探讨如何才能更好地让系统演进到Servicemesh架构。如果对于Servicemesh本身概念、发展现状以及为什么需要它不清楚的话，可...