98708775c8549356aca9e149134d776f
微服务入门,看这一篇就够了 | 分享会演讲稿

微服务,这其实是一个比较大的概念,就像问什么是「人工智能」,什么是「大数据」,什么是「区块链」一样,似乎很熟悉,但是,好像又说不出什么来。

上次在讨论产品架构的时候,我们谈到了微服务的这个方向,而我在之前公司也接触过一些这方面的工作,一直想要整理一下,所以,借着这个机会,整理出来,分享给大家,耽误大家大概半个多小时的时间,相信一定能有一些收获。

我在整理的过程中,就发现,原来之前我接触的那些工作,实在是冰山一角,微服务涉及到的内容,实在太多了,就像之前同事分享过的「数据挖掘和人工智能」课题一样,听上去很熟悉的一个话题,其实里面的内容很深且广。

目录

下面我就从这三个方面来讲一下:

  • 第一点,什么是微服务?这里会讲到微服务的发展过程;
  • 第二点,讲一下微服务架构到底包含哪些内容,这块是微服务的核心内容;
  • 第三点,简单谈一下,咱们的产品接下来可以尝试从哪个方向去做,当然这里只是给个建议,具体技术实现,可能还需要技术团队去研究。

什么是微服务

首先来看下,什么是微服务。每一个技术的发展都是由业务驱动的,这个大家没有什么异议吧。

正是由于当前技术方案已经不能满足业务需求,我们才会去研究新的技术方案,于是,就会出现一堆新的技术名词。什么负载均衡,什么 Redis,什么 MemCache 等等。

微服务也就是近几年才诞生的一个新概念,诞生的过程,我希望通过一个简单的故事介绍一下。

故事来源:https://www.zhihu.com/question/65502802
我会做一些精简,详细故事可去原文查看。

小明和小皮一起创业做网上超市,小明负责程序开发,小皮负责其他,这个「其他」一般是指产品经理。很多时候,一个程序员,一个产品经理就组成了一个创业团队。

最开始的时候,网站的功能很简单,实现业务核心功能,满足用户基本需求,就可以了,所以,第一版产品很快就上线了,它的架构大概如下图所示:

这大概是很多初创团队产品最初的样子,分为前台,后台,数据库。

然而随着业务的发展,出现了各种竞争对手,在竞争的压力下,小皮认为,需要开展一些营销手段了(新的需求产生新的功能)。

除了新增营销的相关功能,还为了精准营销,开发了数据分析模块,同时,也支持了移动端设备,开发了微信小程序以及 APP。

开发任务多了起来,开发人员不够了,于是团队又加了一个人,负责移动端的开发。在这个阶段,产品的架构图大致如下图所示:

可以看出,功能更加的复杂了,而整体架构没有发生太大的变化,依然是分为前台,后台以及数据库。

但是,这种架构会出现很多的问题,例如:

  • 代码重复。有很多相同业务逻辑的代码在不同的模块中;
  • 应用边界模糊,功能归属混乱。单个应用为了给其他应用提供接口,渐渐地越改越大,包含了很多本来就不属于它的逻辑。
  • 功能堆积,出现性能瓶颈。管理后台在加入数据分析和促销管理相关功能后出现性能瓶颈,影响了其他应用;
  • 开发、测试、部署、维护愈发困难。即使只改动一个小功能,也需要整个应用一起发布;
  • 团队出现推诿扯皮现象。关于一些公用的功能应该建设在哪个应用上的问题常常要争论很久;

团队很快发现,这不是长久之计,需要对产品架构进行改造,开发团队在完成正常业务的开发外,牺牲了大部分的业余时间,对一些通用的功能模块进行抽象封装,最后产品架构图如下:

在这个阶段,引入了服务化的概念,抽象一些通用的功能模块,封装后形成公用服务,供前台调用。

虽然业务服务分开了,但是依然有一些问题,例如:数据库依然公用,对数据库的调用接口依然混乱。

因此,团队一鼓作气,将数据库也拆开了,各个业务模块形成完全独立的服务,并独立部署在独立的容器里。这时的产品架构图如下:

到这里就有了微服务的雏形,现在简单回顾一下,微服务产生的几个发展阶段:

第一阶段:单体应用阶段,最常见的就是 LAMP 架构,对应上面得的故事,就是前两个发展阶段。这一阶段的优点是学习成本低,开发快,可以快速对产品进行试错,但是缺点也很明显。

第二阶段:服务化,抽象出公用的业务逻辑,形成公共服务。从本地方法调用的方式,变成通过接口远程调用。这个阶段,虽然采用了服务化的思路,但是,某种程度来讲,并不彻底。

第三阶段,微服务,随着 Docker 为代表的容器化技术以及敏捷开发测试的文化驱动下,使得服务化思想进一步发展,形成微服务。它与服务化的差别就是:拆分粒度更细,服务独立部署,独立维护,但对服务治理能力要求高。

微服务架构

一种技术在解决一个问题的同时,势必会带来另外一些问题。我们是否要采取某个技术方案,通常要看,它所带来的利,是否大于弊。

上面我们已经介绍了微服务的发展,从那个例子中可以看出,最后一个阶段的产品架构似乎很完善,但是,随着微服务数量越来越多,它暴露出来的问题也越来越多。

例如,怎么定义服务?如何解决服务之间调用的问题?出现故障了,如何定位哪个服务出现了问题?又怎么来解决?

好多问题,在单体应用阶段可能不值一谈,而一旦微服务数量达到几十个上百个的时候,很多问题就会被成倍放大,而微服务架构就是要去解决这些问题。

微服务架构提出了 6 大组件,分别为:服务描述、注册中心、服务框架、服务监控、服务追踪以及服务治理。

它们就是解决微服务发展过程中的那些问题而诞生。

所以,当我们在谈到微服务架构的时候,就要想到这 6 个组件都描述了哪些内容。

下面将分别来介绍这 6 个组件的基础内容。

服务描述

服务描述要解决的问题有:

  • 服务名叫什么?
  • 调用这个服务需要提供哪些信息?
  • 服务返回的结果是什么格式?
  • 如何解析结果?

我们如何定义服务,以及服务之间如何沟通,这是服务描述要解决的问题,常用的方案有三类:

RESTful API

它主要应用在 HTTP 或 HTTPS 协议的接口下,在非微服务的架构体系下,也广泛被采用。

这种方案的优点是,服务调用方几乎没有学习成本,适用于跨业务平台之间的调用。例如我们常看到平台提供 URL 供开发者调用,采用的就是这种方式。

XML 配置

它主要应用于 RPC 协议的服务。它相对于 RESTful API 会更加的高效,性能比 HTTP 协议要好。

但是,这种方式对业务代码的侵入性比较高,当配置有更新的时候,服务提供方以及服务调用方都要做相应的更新,它更适用内部系统之间的调用。

IDL(Interface description language)

top Created with Sketch.