利用开源社区打造微服务生态体系

Abstract

在微服务方兴未艾如火如荼之际,如何打造适合自己公司实际情况的微服务框架?如何实现以微服务为核心的完整的开发生态体系?开源社区为此提供了哪些支持?面对眼花缭乱的众多技术,该如何抉择?

Publication
中生代技术十月十城广州站线下分享
Date

备注: 广州地区难得的一次技术分享会议。


利用开源社区打造微服务生态体系

前言

大家好,我是敖小剑,今天给大家分享的主题是”利用开源设计打造微服务生态体系”。

主要内容如下:

内容分为三个大的部分:

  1. 微服务的核心技术
  2. 目前可选的开源微服务框架
  3. 为微服务提供支撑的基础设施

需要说明的是,由于时间有限,而分享的内容数量太多,因此:

  1. 内容都只是罗列,不展开具体介绍
  2. 个人知识面有限,列举过程中范围覆盖不足有所遗漏是必然的
  3. 部分场景我会给出一些个人建议,但是请注意这些都是我的一家之言,仅供参考

下面列出的是今天将会介绍的内容,数量非常多,可谓繁星璀璨。

第一部分:核心技术

现在开始第一个部分:核心技术。

内容主要是第一排的四个技术:

  • 进程间通讯
  • 服务注册与发现
  • 负载均衡
  • 熔断

第二排的三个内容基本都会在类库或者框架中包含,通常不会单独放出来,因此我们不详细展开。

在展开讲述进程间通讯之前,额外指出一个对微服务而言及其重要的概念:

在微服务架构中,为了彻底隔绝不同服务,采用了最坚决的方案,强制要求服务之间:通过 远程访问 方式进行通讯

在这点上,微服务和以OSGi、jigsaw为代表的Java模块化方案形成鲜明对比。

进程间通讯的方式比较多,其多样性体现在两个方面:

  • 有三种风格的解决方案:REST,RPC 和 定制
  • 交互方式有两个维度:按照交互对象的数量分为一对一和一对多,按照应答返回的方式分为同步和异步。

两个维度组合之后的可能性如图:

目前业界常见的网络类库:

考虑到 netty 通常会是大多数人的选择,这里再展开谈一下 netty 的版本选择问题:

需要特别强调的是: netty 5.* 版本因为 ForkJoinPool 引入了太多复杂度而又未能带来明确的性能提升,已经被 netty 官方放弃,不再继续。使用 netty 5.* alpha 版本的同学请回退到 4.0 或者 4.1 版本。

Rest 研究不多,只能给出一点简单的建议。

RPC框架,业界数得上数的大概有十几种,这里只详细介绍三种,分别代表老中新三代RPC框架。

以下是个人给出的建议:

提醒一点的是:如果需要支持移动设备,如果想要用HTTTP 2 的新特性,那么就只能选择gRPC了。

谈谈第三条路线:定制。选择这种方案的同学也不少。

消息队列的选择,同样很多,这里列出三种常见的加一个特例 NSQ。

首先看服务注册和服务发现,在实现时根据对一致性要求的不同,分成两个流派:

  1. 强一致性

    比较常见的分布式一致性协议是 PAXOS 协议和 Raft 协议。相比 PAXOS 而言,Raft 协议易于理解和实现,因此最新的分布式一致性方案大都选择 Raft 协议。

    zookeeper 采用的是 PAXOS 协议(实际为改进版本ZAP),而 Raft 协议那边主要是 consul 和 etcd。

  2. 弱一致性

    如果对一致性要求不高,可以选择以 DNS 为基础的方案,也可以像新浪微博的 Vintage 一样基于 Redis 。

常见的强一致性方案如下:

弱一致性方案比较少,一般多用于 REST 或者 HTTP + json / web service 等简单场合:

负载均衡的方案选择,注意区分服务器端负载均衡和客户端负载均衡。

熔断器目前只有一个可选的开源方案,之前有同学吐糟说 Hystrix 的设计和实现不好,但是在2016年又改进了很多。

第二部分:微服务框架

在国内讨论SOA、服务化、微服务时,dubbo 总是一个绕不开的名字。个人对 dubbo 的评价是”国内SOA框架集大成之作”,基本上一个SOA框架应有的功能都有了。

回顾一下 dubbo 曾经辉煌的历史:

再对比一下现状,实在令人感叹:

从时间线上来看 dubbo 的崛起和兴盛,犹如流星划过夜空.

对 dubbo 的总结,有比较多的个人情绪在,仅供参考。

Motan,能否接过 dubbo 的大旗?

发现每个服务化框架出来,都要被问一个问题:为啥你们不直接用 dubbo 呢? Motan也未能免俗 :)

补充:这也是我自己不选择 dubbo,而是新设计 dolphin 微服务框架的重要理由之一。改造成本远不是一句轻巧的”稍微改改”那么简单。

Motan的技术栈:

下面介绍业界大佬 Netflix 出品的重量级开源产品 OSS 套件。

Netflix 比较有意思的一个做法是他的组建拆分的比较细致,每个独立功能都拆分为单独的组件,方便按需选择,赞一个。

个人对 OSS 的一些看法,属于鸡蛋里面挑骨头性质,仅供参考。

下面开始介绍另外一位业界超重量级大佬的一系列作品,所有Java同学都最熟悉不过的 spring。

在介绍spring为微服务提供的支持之前,我们先回顾一下过去这十四年spring一路的历程:

开始大叔式的怀旧环节,想当年我们看这几本书的时候,我们还那么年轻 :)

唠叨几句:Rod Johnson 大叔(现在可能要称为大爷了) 是我最敬仰最崇拜的业界大神之一。做技术能做到他这水准,此生无憾。

在spring从2002年出道开始,这十几年间出了很多里程碑式版本,增加了很多重量级的功能。但是,个人评价,2014年spring boot的问世,才是最近三五年间spring最大的变革和重新思考。

springboot的出现,代表着spring已经不再沉迷于贪吃蛇游戏,而是开始反省自身和自我改造,对于一个发展了十多年的老框架来说,认识到这点,远比加一两个新功能重要的多。

springboot的功能介绍。

对 spring boot 总结,这也是我选择 spring boot 作为新的 dolphin 微服务框架的基石的重要理由。

spring cloud 出场,2015年才出来的新面孔。

承载着spring对微服务架构领域的众望和抱负。

一出场,就是大量的子项目,这里只列出平时比较常用的一些:

Spring Cloud Netflix 子项目的出现,更像是spring之前的做事风格,做他最擅长的领域:集成。

以下内容是后面补充,没有在会场直接说,纯属个人吐糟:

对spring cloud的个人评价:想法很好,出发点正确,市场空缺而切入的时机很合适。但是,spring cloud的实际表现,总给人一种束手束脚,瞻前顾后,小富即安的感觉。对比十几年前 Rod Johnson 大叔意气风发,气壮山河,谈笑间掀翻EJB的王座的表现,如今的spring cloud,能力不足,信心不够,格局太小,难成大器。期待后面能有转变。

下面是对目前微服务框架的个人看法:

第三部分:基础设施

由于演讲时间只有一个小时,因此基础设施的很多内容无法罗列,这次只是介绍了其中小部分的内容。

分布式配置管理的目前主流底层存储的方案,如果自己动手打造那么可选的无非就是下面这些:

也可以选择现有成型的开源产品:

APM领域的选择,商业产品很多,但是开源的选择实在不多:

在日志分析领域,ELK是王者,但是也有新秀出场:

结束语

洋洋洒洒的列举了几十个名字,但并不是让大家每个名字都去探索一遍,日常中如果需要做技术抉择,我有两句话:

  1. 仰望星空,看弱水三千:眼界要开阔,知识面要广,哪怕只是精通各种名字,至少,知道在某个地方有个好东西,知道某个领域有其他的选择
  2. 立足当下,吾只取一瓢:最终还是要落地的,能玩的转的东西才是好东西。另外,好东西虽多,找到一个能适合自己,能解决问题的就好了,别贪心,别贪多