Lighting@刘迎光

Tag - 微服务

微服务指南走北（二）：微服务架构的进程间通信（IPC）
微服务 MicroService    2017-03-26 08:37:12    1279

先抛出几个问题

  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 这些编程语言间无缝
微服务指南走北（三）：Restful API 设计简述
微服务 MicroService    2017-03-26 08:37:12    1299

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. 或
  3. 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.
微服务相关技术问答
微服务 MicroService 技术问答    2017-02-17 12:47:40    1102

请大家在这里留言以便搜集问题

可以介绍一下使用微服务实现项目的模式吗？

  1. 各服务之间的调用方式。
  2. 使用微服务之后遇到的一些问题。
  3. 项目各层级的大致流程图。

2017-04-07 13:08:50

问题：服务治理，监控有没有好的方案？

答：这个具体要看你的服务的运行环境，如果是docker，则需要使用像Prometheus之类的容器监控方案来监控。

2017-04-07 11:32:47

问题：API网关的实现技术方案？目前有此成熟开源项目吗？除了kong

答：目前常见的有kong、TYK等，我认为目前还是没有比较成熟的解决方案。鉴于很多服务需要将自己的权限等数据与网关结合，其实使用目前的多数网关产品都是不合适的。不过可以采用类似kong之类的网关，倒是可以自己编写相应的插件来实现。如果使用标准的身份验证的几种模式（HTTP Basic、API KEY、Oauth2、JWT等）已经足以满足需求的话，那么使用哪个网关产品其实差别不大。

问题：服务的编排有没有技术方案？

答：服务的编排目前并没有确切的技术方案，毕竟业务不同，所需要处理的事务也不同。但是有几点可以注意的：
1. 建议采用事件驱动来解决事务性：当有事件发生的时候，某个微服务就会发布事件，而其他相关服务则是订阅此事件（需要用到消息中间件实现）。当订阅事件的服务收到事件后，这些微服务就可以更新对应的业务实体。
2. 实现原子化：对于第1点，消息中间件建议有本地化存储的或者存储在单独的一张表来存储事务关系来模拟消息队列模式。

问题：分布式服务的跟踪？

by 刘迎光@萤火虫工作室
OpenBI交流群：495266201
MicroService 微服务交流群：217722918
mail: liuyg#liuyingguang.cn
博主首页（==防止爬虫==）：http://blog.liuyingguang.cn

4/4
Copyright©2016 - 2021   沪ICP备17020857号-1    
Proudly powered by LightingLYG