小白入门微服务-什么是微服务

阅读本文大约需要 6 分钟

概述

前言

什么是微服务

微服务的特征与优势

微服务的不足

微服务通信方式

我应该使用微服务吗?

后记

前言

大半年前,我第一次听说【微服务】这个词,当时由于好奇心,就 Google 了一下这个词,从此埋下了一颗学习微服务的心。在前半年的时间里因为忙,所以抽不出完整的时间块来学习微服务。但都有使用闲碎的时间来看相关的概念与架构。最近总算是有点时间了,我觉得光看概念是没有用的,要真真实实地实践一下,才能真正学到东西。这才有了这篇文章(后面会有系列文章)。

什么是微服务

我们就以微信为栗子,来解释一下微服务。首先假设你要做一款简化版的微信产品,他只有如下几个功能。那么你的初期系统设计应该是这样的:

微信单体架构

随着时间的迁移,我们日子来到了 2019.01.01 00:00 跨年,此时此刻,很多人都在发朋友圈。朋友圈接口访问量很大很大很大,服务器访问峰值瞬间冲顶,那么我们可以开始做集群操作。也就是整一个服务器做集群操作。那么我们的注册登录接口、支付接口、聊天接口也有了一个复制集,在此时此刻这几个接口是比较鸡肋的,没有很大的访问量,那我们能不能只将朋友圈的接口做扩容呢?答案当然是可以的,且看下图 -- 微服务架构

微信微服务架构

那么当我们微服务架构遇到 2019.01.01 00:00 跨年,会怎么样呢?

直接水平扩展朋友圈服务,如下图,峰值压力有所缓解。

微信微服务架构

然而在各个功能拆解成一个个的服务之后,由客户端直接访问各个微服务,这样就直接将我们的服务暴露了出来,客户端也需要定制相应的访问策略。这样的设计还是没有那么友好。那么,我们能不能将所有微服务统一到一起呢?且看下图:

微信微服务架构plus

在这张示例图中,多了一个 APIGateway 模块,那 API 网关是用来干嘛的呢?

一般情况下 API 网关有一下任务:路由,安全,限流,缓存,日志,监控,重试,熔断等,然后服务层就纯粹的做业务,也能够很好的保证业务代码的干净,不用关心安全,压力等方面的问题。

当然,以上示例图只是一个小小的演示,真实的使用中,要比这个复杂得多,这里只是先抛出概念,供大家理解。

维基百科对微服务的定义:

微服务(Microservices) 是一种软件架构风格,它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础,利用模组化的方式组合出复杂的大型应用程序,各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通讯。

微服务的特征与优势

微服务特征:

单一职责;

轻量级的通信;

隔离性,运行在自己的进程中,不会相互干扰;

有自己的数据,数据的独立性,每个微服务都有自己的数据库;

技术的多样性,选用适合的技术做合适的事;

一个微服务就负责某一个职责,就像朋友圈服务,它就只负责朋友圈的【增删查】功能,与其他服务独立开来,可以选用不同的技术语言,来满足不同的需求。

微服务的优势:

独立性

每个微服务的构建、部署、扩容、缩容、数据库都是独立的。数据库表修改时,互补影响。

敏捷性

功能单一、可快速添加新需求

技术栈灵活

可以发挥不同语言的优势,例如:用 python 来爬数据,nodejs 来处理 io 流

高效团队

可以分发给不同的团队进行开发

微服务的不足

额外的工作;

数据一致性;

沟通成本;

debug 单元测试困难;

需要额外工作,例如:服务的拆分(即如何拆分微服务,哪些服务应该拆到一起)、服务注册、服务发现、微服务间的通信。每个微服务都持有独立的数据库,无法做到数据强一致性,只能做到最终结果一致性。做微服务也会增加团队的沟通成本。

微服务通信方式

微服务可以使用两种基本消息传递模式 -- 同步与异步消息传递,来与其他微服务通信。

同步通信。 在此模式下,一个服务使用 HTTP 或 RPC(Remote Procedure Call,翻译过来为“远程过程调用”) 框架等协议调用另一个服务公开的 API。 此选项之所以称作同步消息传递模式,是因为调用方需要等待接收方返回的响应。比较通用的 RPC 框架有:gRPC(Google)、Thrift(Apache)

异步消息传递。 在此模式下,服务可以在不等待回应的情况下发送消息,然后一个或多个服务以异步方式处理该消息。比较流行的消息队列有:RabbitMQ、ZeroMQ、Kafka、ActiveMQ

至于具体怎么通信,后面会有详细的分享。本文只是先介绍微服务如何通信。

我们应该使用微服务吗?

微服务已经成为一种热门的架构模式了,打开各大技术类网站几乎都少不了微服务的身影。但微服务真的适合我们当下的用户规模与公司级别吗?这个问题,其实也没有比较统一的答案。在我看来,其实大部分小公司是用不到微服务的,因为其不足远大于其优势,单体应用做好优化、数据库读写分离、集群、负载均衡,就能应对日常的流量。当你以上的优化都做了,还是撑不住压力的话,就可以考虑微服务了。当然,服务架构选型还是看不同情况和公司意志的,如果有必要做跨语言等其他需求,那就做微服务的。

后记

  • 发表于:
  • 原文链接https://kuaibao.qq.com/s/20180907G1QJVG00?refer=cp_1026
  • 腾讯「云+社区」是腾讯内容开放平台帐号(企鹅号)传播渠道之一,根据《腾讯内容开放平台服务协议》转载发布内容。

扫码关注云+社区

领取腾讯云代金券