什么是微服务?

老余博客

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

什么是微服务

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

微服务-1.png

微信单体架构

随着时间的迁移,我们日子来到了 2019.01.01 00:00 跨年,此时此刻,很多人都在发朋友圈。朋友圈接口访问量很大,服务器访问峰值瞬间冲顶,那么我们可以开始做集群操作。

也就是整一个服务器做集群操作。那么我们的注册登录接口、支付接口、聊天接口也有了一个复制集,在此时此刻这几个接口是比较鸡肋的,没有很大的访问量,那我们能不能只将朋友圈的接口做扩容呢?答案当然是可以的,且看下图 -- 微服务架构

微服务-2.png

微信微服务架构

那么当我们微服务架构遇到 2019.01.01 00:00 跨年,会怎么样呢?直接水平扩展朋友圈服务,如下图,峰值压力有所缓解。

微服务-3.png

微信微服务架构

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

微服务-4.png

微信微服务架构plus

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

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

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

维基百科对微服务的定义

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

微服务的特征与优势

微服务特征:单一职责;轻量级的通信;隔离性,运行在自己的进程中,不会相互干扰;有自己的数据,数据的独立性,每个微服务都有自己的数据库;技术的多样性,选用适合的技术做合适的事。

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

微服务的优势:独立性、敏捷性、技术栈灵活、高效团队

微服务的不足:额外的工作、数据一致性、沟通成本、debug 单元测试困难、需要额外工作。


赞(0)
分享
文章版权声明:除非注明,否则均为老余个人博客原创文章,转载或复制请以超链接形式并注明出处。

发表评论

评论列表 (有 0 条评论,2185人围观)
取消
微信二维码
微信二维码
支付宝二维码
取消
老余博客微信公众号二维码