1 什么是微服务
定义:微服务的概念最早是在 2014 年由 Martin Fowler 和 James Lewis 提出,微服务是一种架构风格,将单体应用划分成一组小的服务,服务之间相互协作,实现业务功能;每个服务运行在独立的进程中,服务间采用轻量级的通信机制协作(如HTTP);每个服务围绕业务能力进行构建,并且能够通过自动化机制独立部署;服务会使用最小规模的集中管理 (例如 Docker)技术,每个服务可以使用不同的开发语言与存储技术。它有以下特点:
● 一组小的服务,微服务主张将大一体的服务拆成小的服务,架构师要取舍拆分粒度。
● 独立的进程。
● 轻量级通信,比如http。
● 基于业务能力,比如商品服务,用户服务,基于业务能力构建微服务。
● 独立部署,独立维护、独立迭代和部署。
● 无集中管理,分散治理,各个微服务可以独立选择合适自己栈。
2 微服务利弊
微服务也不是银弹,当你搞不定单块应用的时候,也别指望微服务能拯救你。
优势:
● 强模块化边界(以服务的方式作为边界)
● 可独立部署
● 技术多样性
劣势:
● 分布式复杂性
● 最终一致性
● 运维复杂性
● 测试复杂性
3 康威法则
康威法则:设计系统的架构受限制于产生这些设计的组织沟通结构。简单理解是就是系统架构(产品)必然要反应组织结构。
单块应用随着业务的发展,之前由一个团队变成了多个团队维护&开发,如果不对单块应用进行升级&拆分,这个就会违反康威法则,就会出现一些矛盾、协调成本比较高、交付效率低等问题。怎么解决这个问题呢?微服务就可以解决,对单块应用进行拆分。
4 企业应该在什么时候开始考虑引入微服务
先看下面一张图,横坐标是复杂度,纵坐标是生产力。从图中也可以看出,刚开始时候业务复杂度不高、系统功能也不多、商业模式没有得到验证,此时单块应用的生产力和效率比微服务高。随着业务逐步增长,业务的复杂度逐步提升,团队也原来越多,根据康威法则单块应用已经不在适合,此时可以考虑选择微服务架构,怎么权衡:这个需要架构师做出取舍,比如团队接近百人规模,就可以考虑采用微服务。
一开始的系统是直接选择微服务还是单块架构呢,尤其是新业务不推荐使用微服务,建议单块优先,主要原因以下:
● 一开始对问题领域不是很理解,很难把控怎么拆分服务以及划分边界
● 商业还没有被验证过,可能会失败,前期投入过高,而且生产力低不利与业务快速试错
5 什么样的组织架构更适合微服务
6 微服务中台战略
一线互联网标准的层次架构,可以分为四层:Iass->Pass->核心领域服务层(业务中台)>业务前台
7 服务分层
如下图所示,逻辑上大体可以分为两层。说明:BFF,即 Backend For Frontend(服务于前端的后端),也就是服务器设计 API 时会考虑前端的使用,并在服务端直接进行业务逻辑的处理,又称为用户体验适配器。
8 微服务技术架构体系
如下图所示微服务架的六大层次,可以认为是微服务基础技术架构的一个模板。
9 微服务技术架构体系
三种主流的服务发现模式,具体如下:
● 传统基于LB的模式,有一个独立的LB。优点:使用简单 缺点:集中的LB 变成了单点,性能消耗(需要穿透LB)。
- 进程内LB模式,LB维护在消费进程中,优点:没有集中式LB不存在单点问题,性能会比较好,缺点:需要为不同语言开发不同客户端,多语言支持成本会比较
- 主机独立LB模式,每一个客户端,主机上部署一个LB。优点:没有集中式LB不存在单点问题,性能会比较好,也能支持多语言。缺点:运维成本会比较高。
参考文献
[1] 极客时间-微服务架构核心20讲
[2] https://www.martinfowler.com/articles/microservices.html