老蔡的个人专栏正式成立,以后工作中遇到的技术问题,或者生活中对一些事物的见解,都会和大家分享!独乐乐不如众乐乐!

微服务架构的百家解读(之一)

项目架构 BlandonTsai 566℃ 0评论

微服务

花了很长时间去研究到底什么是微服务,说下我的学习心得。

1.微服务是借用 SOA 的架构风格来构建单一产品的架构形式

当然这个单一产品有点模糊,是需要根据自身业务来理解的。例如,一套电商系统就是一个单一产品,虽然它肯定是要包含用户子系统、支付子系统、库存管理子系统等等。传统的构建方式,是通过进程内组件的方式来实现这些子系统,例如 Java 的 Spring Bean 等等。而微服务下,这些子系统是通过彼此独立的服务的方式来构建,服务间通过且仅应该通过 rpc 或者 restful api 的方式来通信。

SOA 更多的是一种架构风格,一种通过彼此独立的服务来构建系统的风格,它的范畴要比微服务大的多,例如 SOA 架构的系统里,可以有很多产品,外部的访问点可以有多个,任何 SOA 里的系统都可以单独为外界提供服务,用户可能单独使用其中的某个系统,所以 SOA 系统中需要的是一个消息总线;而微服务是一个单一产品,对外只能有一个访问点,回到电商的例子,用户是不可能单独使用库存子系统,用户使用的肯定是一个完整的电商系统,因此微服务需要的是一个 API 网关。

2.什么才是真正的微服务

我理解,除了通过跨进程接口来访问服务外,微服务最核心的是数据独立,即产品中不会有多个服务去共享同一个数据源,一个数据源一定只被一个服务专享,这里要澄清下微服务中同一个服务还包括通过负载均衡下同一类服务的一群服务,这里用“个”代“类”。

为什么要强调数据独立,现在的架构设计,可以说100%的都会要求架构设计低耦合高内聚,这方面的好处不多说,写过几年程序的都有心得。那么在一个复杂产品(系统)中,最大的耦合是什么呢,实际上是数据耦合,正是数据耦合导致我们的产品成为一个“巨”系统难以拆分。例如电商系统中,显示用户的订单,还需要拿到些例如用户电话号码、地址之类的信息,因为开发时新的开发工程师不了解系统,没有通过用户服务直接从数据库拿了用户信息,就这样订单系统和用户系统耦合了,虽然他们是两个服务。结果就是有一天发现订单系统压力太大,升级或者拆分数据库,却因为和用户的数据耦合在一块不得不连带升级用户的服务,或者想要改进用户的服务,却发现订单系统使用了同一份数据格式,结果用户系统的修改导致了订单系统的不可用。一个成熟的产品,往往要历经数年的开发,数据库一旦共享,数据之间的耦合就会越来越深,最终发现除了推倒重来外没有人再能理清里面的脉络!

所以,服务间数据独立、仅通过接口互相访问才是评判是否是微服务系统的标志(SOA倒不强调这个),而不是通过服务的大小,实际上,因为微服务的“微”字,给很多人包括我学习时造成了很大的困扰,甚至有位经验丰富的架构师告诉我,微服务就是一个接口一个服务。另外,数据源要求彼此独立,实际上也告诉了我们该如何切分服务,就是通过考察数据源如何独立、隔离,来划分各个服务。

3.那些 API 网关、熔断、负载均衡和服务发现或者Docker什么的是评判是否是微服务的吗?

除了 API 网关在概念上是必需的,其它那些实际上不是微服务的核心概念里需要的,它们要么是用来让微服务可以运行的更好的工具,或者是能实际落地的工具。

API 网关

微服务是一个产品,所以一个产品必然需要一个统一的访问入口,通过 API 网关,客户端的请求才会导航到真正的服务上。

熔断

微服务概念本身可以不要这个服务,但真正的生产环境是必需的。开发过分布式系统的工程师应该有感受,当某个服务特别慢时,依赖它的服务的请求就会堆积在这里,导致整个系统的处理全部变慢(雪崩效应),这时候通过熔断,我们给过多的请求直接返回错误,至少保证系统能够运行下去。

负载均衡

负载均衡本身不多说,这里只提一下为什么微服务推荐用 restful api 的方式,restful 是基于 http 的,一方面请求无状态才利于搞负载均衡,另一方面针对 http 的负载方案最多也最廉价。

服务发现

一个产品有那么多的服务,哪个服务没上线或者崩溃了,依赖它的服务是需要知道的。

Docker

还是,一个产品有那么多的服务,可能会使用不同的语言编写,可能会使用不同类型的数据源,有时候是MySQL,有时候是 Mongo 这样的 NOSQL,部署一次懂点运维的会知道有多繁琐和容易出错,借助 Docker,和各种编织工具,我们可以像在 iPhone 上安装 APP 一样快速部署,可以说是 Docker 让微服务成为了现实中可落地的方案。

转载请注明:似水流年 » 微服务架构的百家解读(之一)

如果觉得文章还不错,欢迎打赏
喜欢 (0)or分享 (0)
发表我的评论
取消评论