Category - 微服务(IT)

微服务 MicroService    2017-03-26 08:37:12    937

先抛出几个问题

  1. 微服务架构的交互模式有哪些?
  2. 微服务常用的进程间通信技术有哪些?
  3. 如何处理部分请求失败?
  4. API的定义需要注意的事项有哪些
  5. 微服务的通信机制与SOA的通信机制之间的关系与区别

微服务架构的交互模式

一对一还是一对多?

  1. 一对一:每个客户端请求有一个服务实例来响应
  2. 一对多:每个客户端请求有多个服务实例来响应

同步还是异步?

  1. 同步模式:客户端请求需要服务端即时响应,甚至可能由于等待而阻塞
  2. 异步模式:客户端请求不会阻塞进程,服务端的响应可以是非即时的

一对一的交互模式有以下几种方式:

  1. 请求/响应:一个客户端向服务器端发起请求,等待响应,客户端期望此响应即时到达。在一个基于线程的应用中,等待过程可能造成线程阻塞。
  2. 通知(也就是常说的单向请求):一个客户端请求发送到服务端,但是并不期望服务端响应。
  3. 请求/异步响应:客户端发送请求到服务端,服务端异步响应请求。客户端不会阻塞,而且被设计成默认响应不会立刻到达。

一对多的交互模式有以下几种方式:

  1. 发布/ 订阅模式:客户端发布通知消息,被零个或者多个感兴趣的服务消费。
  2. 发布/异步响应模式:客户端发布请求消息,然后等待从感兴趣服务发回的响应。

微服务常用的进程间通信技术

  1. REST:REST即表述性状态传递(英文:Representational State Transfer,简称REST)是Roy Fielding博士在2000年他的博士论文中提出来的一种软件架构风格。它是一种针对网络应用的设计和开发方式,可以降低开发的复杂性,提高系统的可伸缩性。
  2. Thrift:thrift是一个软件框架,用来进行可扩展且跨语言的服务的开发。它结合了功能强大的软件堆栈和代码生成引擎,以构建在 C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, and OCaml 这些编程语言间无缝
微服务 MicroService    2017-03-26 08:37:12    885

API的定义取决于选择的IPC通信方式,如果是消息机制(如 AMQP 或者 STOMP),API则由消息频道(channel)和消息类型;如果是使用HTTP机制,则是基于请求/响应(调用http的url),这里我们先简述下RestfulAPI的定义。

设计原则

域名

应该尽量将API部署在专用域名之下,如:

  1. https://api.example.com

也可以放在主域名下:

  1. https://example.org/api/

版本

放入到头信息的Accept中
制定版本并在版本之间平缓过渡对于设计和维护一套API是个巨大的挑战。所以,最好在设计之初就使用一些方法来预防可能会遇到的问题。
为了避免API的变动导致用户使用中产生意外结果或调用失败,最好强制要求所有访问都需要指定版本号。请避免提供默认版本号,一旦提供,日后想要修改它会相当困难。
最适合放置版本号的位置URL中,或者是头信息(HTTP Headers)中在 Accept 段中使用自定义类型(content type)与其他元数据(metadata)一起提交。

  1. https://api.example.com/v1/
  2. Accept: application/vnd.heroku+json; version=3

提供 Request-Id

为每一个请求响应包含一个Request-Id字段,并使用UUID作为该值。通过在客户端、服务器或任何支持服务上记录该值,它能主我们提供一种机制来跟踪、诊断和调试请求。

路径

资源名

在RESTful架构中,每个网址代表一种资源(resource),所以网址中不能有动词,只能有名词,而且所用的名词往往与数据库的表格名对应。一般来说,数据库中的表都是同种记录的”集合”(collection),所以API中的名词也应该使用复数。
举例来说,有一个API提供动物园(zoo)的信息,还包括各种动物和雇员的信息,则它的路径应该设计成下面这样。

  1. https://api.example.com/v1/zoos
  2. https://api.example.com/v1/animals
  3. https://api.
4/4