云原生架构下微服务最佳实践云原生架构下微服务最佳实践-如何拆分微服务架构如何拆分微服务架构
1 微服务架构
本章内容从问题开始,循序渐进,带领读者逐步深入微服务架构的各个角落。
1.1 微服务架构的起源
2005年,Peter Rodgers博士在云端运算博览会上提出的微Web服务(Micro-Web-Service),将程序设计成细粒度的服务
(Granular Services),以作为Microsoft下一阶段的软件架构,其核心思想是让服务由类似Unix管道的存取方式使用,而且复
杂的服务背后是使用简单URI来开放界面,任何服务都能被开放(exposed)。这个设计在HP的实验室被实现,具有改变复杂
软件系统的强大力量。
2014年,Martin Fowler与James Lewis共同提出了微服务的概念,定义了微服务架构是以开发一组小型服务的方式来开发一个
独立的应用系统,每个服务都以一个独立的进程的方式运行,每个服务与其他服务使用轻量级(通常是HTTP API)通信机
制,这些服务是围绕业务功能构建的,可以通过全自动部署机制独立部署,同时服务会使用最小规模的集中管理(例如
Docker)能力,服务可以用不同的编程语言和数据库。
实际上,微服务的诞生绝非偶然,敏捷开发帮助我们减少浪费,快速反馈,以用户体验为目标;持续交付促使我们更快、更可
靠、更频繁地改进软件;基础设施即代码(Infrastructure As Code)帮助我们简化环境的管理,这些都是推动微服务诞生的重
要因素。如果没有这些基础,微服务架构在展现魅力的同时,可能由于各种问题导致最终失败。
从SOA架构到服务化架构、再到微服务架构,是一个逐步演进的过程,Amazon被认为是微服务的鼻祖,2015年我曾经接触
过一个Amazon的工程师,他并不是特别了解微服务这个名词,直到看完Martin Fowler关于微服务的文章,才发现自己一直在
做的就是微服务架构。可以说微服务架构并不是什么技术创新,而是开发过程发展到一个阶段对技术架构的要求,是在实践中
不断摸索而来,每个公司所信奉的架构思想有相同之处,但是也不尽相同。这种化繁为简的拆分方式,不只在技术上带来突
破,更带来了很多潜在的价值,如关注点分离、沟通效率提升、快速演进、快速交付、快速反馈等。
1.2 为什么采用微服务架构
1.2.1 单体架构VS微服务架构
就像很难用一个绝对的方式去判断架构好坏一样,在大多数场景下,我们也很难从一个外部的视角去判断服务拆分粒度的合理
性,需要对上下文非常了解才能做出一个好决策。例如,团队规模多大,代码规模多大,有没有平台化,有没有工具链,是否
需要持续交付,团队文化如何等。因此,一个外部的架构师是很难在短时间内将架构规划合理的,这需要一个过程,当真正了
解这一切之后,不断权衡,最终确定。在划分之前,有必要参考表2-1,综合各方面的情况,最终做出决策。
表2-1 单体架构VS微服务架构
因素 单体架构
微服务
架构
说明
交付速度 较慢 较快
服务拆分后,各个服务可以独立并行
开发、测试、部署,交付效率提升,
产品的更新速度会更快,用户体验更
好。代码规模越大,微服务的优势越
明显
故障隔离
范围
线程级 进程级
服务独立运行,通过进程的方式隔
离,使故障范围得到有效控制、架构
变得更简单可靠。根据业务的重要程
度划分服务,把核心的业务划分为独
立的服务,这样可以从数据库到服
务,保持有效的故障隔离,进而保持
稳定
整体可用
性
较低 更高
微服务架构由于故障范围得到有效隔
离,整体可用性更高,降低一点故障
对整体的影响
架构持续
演进
困难 简单
由于微服务的粒度更小,架构演进的
影响面就更小。不存在大规模重构导
致的各种问题。微服务架构对架构演
进更友好
评论0