飞污熊博客

静下心来做一件事

高可用HA(High Availability)是分布式系统架构设计中必须考虑的因素之一, 它通常是指,通过设计减少系统不能提供服务的时间。

单点往往是系统高可用最大的风险和敌人,应该尽量在系统设计的过程中避免单点。 高可用保证的原则是”集群化”,或者叫”冗余”:只有一个单点,挂了服务会受影响。 如果有冗余备份,挂了还有其他backup能够顶上。

有了冗余之后,还不够,每次出现故障需要人工介入恢复势必会增加系统的不可服务实践。 所以,又往往是通过”自动故障转移”来实现系统的高可用。

接下来我们看下典型互联网架构中,如何通过”冗余+自动故障转移”来保证系统的高可用特性。

阅读全文 »

Json web token (JWT), 是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准((RFC 7519).该token被设计为紧凑且安全的, 特别适用于分布式站点的单点登录(SSO)场景。JWT的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息, 以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息,该token也可直接被用于认证,也可被加密。

JWT官网:https://jwt.io/

阅读全文 »

Web刚刚兴起的时候,服务器只提供一些简单的HTML页面和链接,用户打开网址去浏览。 并不需要记住每次请求是谁发送来的,每次请求对服务器来讲都是全新的。 既然是浏览,作为一个服务器,为什么要记住谁在一段时间里都浏览了什么文档呢?

但是好日子没持续多久,很快大家就不满足于静态的HTML文档了,交互式的Web应用开始兴起,尤其是论坛,在线购物等网站。 必须管理会话,必须记住哪些人登录系统,哪些人往自己的购物车中放了商品,也就是说我必须把每个人区分开。

由于HTTP协议的无状态特性,必须加点小手段,才能完成会话管理。

本文总结了3种常见的实现web应用会话管理的方式:

  1. 基于server端session的管理方式
  2. 基于cookie的管理方式
  3. 基于token的管理方式

目的是加深对web中用户登录机制的理解,对实际项目开发也有参考价值。

阅读全文 »

Jetty是一个用 Java 实现、开源、基于标准的,并且具有丰富功能的 Http 服务器和 Web 容器。 Jetty 可以用来作为一个传统的 Web 服务器,也可以作为一个动态的内容服务器,并且 Jetty 可以非常容易的嵌入到 Java 应用程序当中。

jetty是轻量级的web服务器和servlet引擎。它的最大特点是:可以很方便的作为嵌入式服务器。 就是只要引入jetty的jar包,可以通过直接调用其API的方式来启动web服务。

阅读全文 »

REST API都是要对外提供服务的,那么文档是必须的。Swagger是一个简单但功能强大的API表达工具。 它具有地球上最大的API工具生态系统,数以千计的开发人员,使用几乎所有的现代编程语言, 都在支持和使用Swagger。使用Swagger生成API,我们可以得到交互式文档,自动生成代码的SDK以及API的发现特性等。

2.X版本已经发布,Swagger变得更加强大。值得感激的是,Swagger的源码100%开源在github

使用Swagger不纯粹是为了生成一个漂亮的API文档,也不纯粹是为了自动生成多种语言的代码框架, 重要的是,通过遵循它的标准,可以使REST API分组清晰、定义标准。

阅读全文 »

RabbitMQ任务调度默认是阻塞的,使用pika中的channel.start_consuming()的时候, 每次收到一条消息后会顺序执行完回调函数,发送ACK的确认消息,然后再执行下一条消息。 虽然说可同时接受多条消息,但是并不能同时处理这多条消息,那么需要自己在代码里面实现任务的并发调度。

在Python里面实现并发方式多种多样,有多线程、多进程、多协程方式,我演示下如何实现。

阅读全文 »

之前写过一篇 使用Ajax实现异步任务 的文章, 介绍了对于需要知道异步处理返回结果的情况,使用Ajax的轮训和长连接方式实现。 但是这两种方式都会生成大量的HTTP连接,对服务器资源是一种巨大的浪费, 这里正式介绍如果通过WebSocket + RabbitMQ来优雅的实现。

阅读全文 »

在教程第二篇里面我们学习了如何实现一个任务队列,异步方式去处理那些比较耗时的任务。 但是如果我们需要调用一个远程主机上面的方法,并且等待它的执行结果呢? 这种模式我们通常将它称为远程方法调用(RPC)。

这一篇我们将利用RabbitMQ来构建一个RPC服务,服务器上面有一个可返回斐波拉契数的函数。 客户端通过rpc调用来获取结果。

阅读全文 »

前面一篇通过使用direct类型的交换机代替fanout广播类型交换机, 实现了一个基于日志级别路由对应的消息的功能。

但是还是有它的局限性——它并不能根据多个条件来实现路由,只能通过完全匹配routing key, 灵活性不够。

比如我想实现仅仅对于那些error级别日志并且由kern生成的日志才记录到文件中。

阅读全文 »

前面一篇实现了一个非常基础的日志系统,交换机将所有接收到的消息广播到它所知道的多个接受者。

这一节我们更进一步,实现订阅部分消息的功能。比如我只讲那些ERROR级别的消息写入日志文件, 同时将所有日志打印到控制台上面。

阅读全文 »