Go语言中文网 为您找到相关结果 6

HTTP API 网关 API-Gateway

Gateway是一个使用go实现的基于HTTP的API 网关。 **特性:** * API 聚合 * 流控 * 熔断 * 负载均衡 * 健康检查 * 监控 * 消息路由 * 后端管理WebUI **能做什么:** * 规划更友好的URL给调用者。 * 聚合多个API的结果返回给API调用者,利于移动端,后端可以实现原子接口。 * 保护后端API服务不会被突发异常流量压垮。 * 提供熔断机制,使得后端API Server具备自我恢复能力。 * 借助消息路由能力,实现灰度发布,AB测试...阅读全文

令人激动的微服务2.0技术栈

作者|Christian 编辑|禚娴静 当下市场瞬息万变,新技术不断涌现,而微服务持续火热。如果说2014年是微服务的元年,那么2015年和2016年则是微服务走下神坛的时刻,越来越多的开发者、架构师们探讨着如何落地,如何解决各种实际问题,而很多技术栈和工具也纷纷涌现。构建微服务时,我们真的深深进入了分析分布式系统 - 一个已经研究了40年以上的技术主题,复杂的自适应系统理论已经深入人心有很长的时间。从技术的角度来看,我们需要解决的事情如下:部署交付API版本控制合同缩放/自动缩放服务发现负载均衡路由/自适应路由健康检查配置熔断器bulk-headsTTL / deadlining延迟跟踪服务因果跟踪分布式日志度量操作与收集Netflix和一些互联网公司作为早期微服务的采用者在这些领域做了很...阅读全文

博文 2017-03-14 11:05:54 Christian

微服务组件之限流器与熔断器

在微服务架构里面一个很常见的问题就是服务之间的延迟和通信失败问题,极端的情况下,甚至会因为某个服务的性能下降或者故障宕机,导致访问超时,层层传递,引发雪崩,最终导致整个系统崩溃,而限流器和熔断器(这两个组件都是客户端的)能很好的解决这个问题,提高系统的可靠性和稳定性 限流器 限流器,从字面上理解就是用来限制流量,有时候流量突增(可预期的比如“双11”,不可预期的微博的热门话题等),会将后端服务压垮,甚至直接宕机,使用限流器能限制访问后端的流量,起到一个保护作用,被限制的流量,可以根据具体的业务逻辑去处理,直接返回错误或者返回默认值等等 golang 提供了拓展库(golang.org/x/time/rate)提供了限流器组件,用法上也很简单直观,通过下面这段代码就可以创建一个限流器 // 每...阅读全文

博文 2018-06-21 18:34:39 hatlonely

hystrix-go

内部组织了一次关于hystrix-go的分享,没想到引起了内部的困惑,对于没有做过分布式系统的开发同学可能根本没有接触过hystrix,学习一个新东西,我个人的一贯思路是按照黄金圈理论。 这里关于hystrix是什么就不描述了,百度一下足够你翻几屏的了。因为目前Team以golang为主要开发语言,所以使用了开源的hystrix-go(https://github.com/afex/hystrix-go).大家先看下面一个例子:var Number intvar Result stringfunc main() { config := hystrix.CommandConfig{ Timeout:2000, //超时时间设置 单位毫秒 MaxConcurrentRequests:8, //最...阅读全文

博文 2018-07-22 23:34:48 GoSnail

阿里P8架构师谈:什么是缓存雪崩?服务器雪崩的场景与解决方案

什么是应用服务雪崩雪崩问题分布式系统都存在这样一个问题,由于网络的不稳定性,决定了任何一个服务的可用性都不是 100% 的。当网络不稳定的时候,作为服务的提供者,自身可能会被拖死,导致服务调用者阻塞,最终可能引发雪崩连锁效应。缓存雪崩当缓存服务器重启或者大量缓存集中在某一个时间段失效,这样在失效的时候,也会给后端系统(比如DB)带来很大压力,造成数据库后端故障,从而引起应用服务器雪崩。雪崩效应产生的几种场景流量激增:比如异常流量、用户重试导致系统负载升高;缓存刷新:假设A为client端,B为Server端,假设A系统请求都流向B系统,请求超出了B系统的承载能力,就会造成B系统崩溃;程序有Bug:代码循环调用的逻辑问题,资源未释放引起的内存泄漏等问题;硬件故障:比如宕机,机房断电,光纤被挖断...阅读全文

博文 2018-09-14 16:55:04 Java_fenxiang

微服务漫游指南(一)

最近几年“微服务”这个词可谓是非常的火爆,大有席卷天下的态势。几乎所有公司都在按照自己的理解实施微服务,大公司也在逐步地把自己庞大的代码库通过一定的策略逐步拆分成微服务。不过如果你在Google上搜一下,你会发现“微服务”这个名词很难有一个明确的定义,不同的人,不同的业务,不同的架构,他们在不同的维度聊“微服务”。 不过总的来说,大家都比较认同的是:“微服务”的核心是把一个大的系统拆解成一系列功能单一的小系统,每个系统可以单独进行部署。这样的好处是显而易见的: 由于单一职责,每个微服务的开发测试会更简单 开发语言和技术方案不受限制,可以发挥不同团队的特长 故障可以控制在单个系统之中 “服务化”使得复用更加便捷 如果要一一列举,还能列举很多很多的优点。总之,微服务看起来还是非常美好的。但是随着...阅读全文

博文 2018-11-03 01:34:46 suoga