他发现了人类行为的一大法则,那就是,为了要使一个大人或小孩极想干某样事情,只需要设法把那件事情弄得不易到手就行了----《汤姆·索亚历险记》
参考书籍:
在了解微服务架构之前,我们有必要了解一下从SOA架构到微服务架构风格的演进的过程,以及这两种架构风格的关系
面向服务的架构是一次具体地、系统性地成功解决分布式服务主要问题的架构模式。 --《凤凰架构》
网上很多文章对于SOA架构的定义都有不同,像Gartnet把它定义为一种软件的设计方法、百度百科把它定义为一个组件模型等等。
从另一个角度来看,SOA其实是拆分复杂单体应用的一种尝试,这种尝试在架构的历史长河中不止一次,像在SOA演进过程中的烟囱式架构(Information Silo Architecture)、微内核架构(Microkernel Architecture)、事件驱动架构(Event-Driven Architecture)。
下面我们就通过了解这些架构的演进过程来了解什么是SOA架构。
一种不能与其他系统进行有效协调工作的信息系统,又称为孤岛系统 - -维基百科
下图为按照烟囱架构理论拆分之后的系统图,每个服务之间的数据是隔离的并不会有数据交互:
烟囱架构设计是一种完全不与其他相关信息系统进行互操作或者协调工作的设计模式。但是这种模式其实根本无法实现,像上图案例:“一个电商项目,系统按照业务可以拆分为用户管理、商品管理、订单管理、支付等系统”,但是按照烟囱式架构的设计理念就无法顺利按照上述的几种业务系统拆分实现,因为像商品管理、订单管理等系统模块都是需要依赖用户管理模块中的人员信息,不管是通过什么方式调用,这里面都涉及到不同的两个系统之间数据的通信与交互,这本身就违背了烟囱式架构“完全不与其他相关信息系统进行互操作或者协调工作”的设计理念。所以说烟囱架构只能永远的在美好的理念世界中存活,在真实架构设计中无法真正去落地实现。
微内核架构又被称为插件化架构(Plug-in Architecture),是一种面向功能进行拆分的可扩展性架构,通常用于实现基于产品的应用 - - 网络
微内核架构式在烟囱式架构的基础上对拆分单体项目的又一次尝试,在烟囱式架构中,没有业务往来关系的系统也可能需要共享人员、组织、权限等一些的公共的主数据,那不妨就将这些主数据,连同其他可能被各子系统使用到的公共服务、数据、资源集中到一块,成为一个被所有业务系统共同依赖的核心(Kernel,也称为 Core System),具体的业务系统以插件模块(Plug-in Modules)的形式存在,这样也可提供可扩展的、灵活的、天然隔离的功能特性。
在微内核架构中有两个核心组件:系统内核、插件化组件。这里的内核系统通常提供系统运行所需的最小功能集,而插件是独立的组件,包含自定义的各种业务代码,用来向内核系统增强或扩展额外的业务能力。(可以类比操作系统中的微内核设计,一通百通!!)
而微内核相比较烟囱架构的无法落地实现,微内核设计理念在桌面应用程序、 Web 应用程序中经常使用,如:Dubbo(SPI机制)、Eclips、IDEA、OSGI、Spring Plugin等
事件驱动架构(Event Driven Architecture,EDA)一个事件驱动框架(EDA)定义了一个设计和实现一个应用系统的方法学,在这个系统里事件可传输于松散耦合的组件和服务之间。一个事件驱动系统典型地由事件消费者和事件产生者组成。事件消费者向事件管理器订阅事件,事件产生者向事件管理器发布事件。 - - 百度百科
事件驱动架构体系结构具备以下三个能力:
事件驱动架构具有以下优势:
当拆分单体尝试到事件驱动架构的同时,远程服务调用的也迎来了一个重要突破,那就是“SOAP协议的诞生”,至此,SOA架构所需要的全部前置条件都已经具备。
SOA相比较上述三种架构涌现出了服务之间的松散耦合、注册、发现、治理,隔离、编排,等等理念。这些在今天微服务中耳熟能详的名词概念,大多数也是在分布式服务刚被提出时就已经可以预见的困难点。SOA 针对这些问题,甚至是针对“软件开发”这件事情本身,都进行了更加系统性、更加具体的探索。
而对于这里的“更加系统性”和“更加具体”引用“凤凰架构”一书来解释:
“更具体”
“更具体”体现在尽管 SOA 本身还是属抽象概念,而不是特指某一种具体的技术,但它比单体架构和前面所列举的三种架构模式的操作性要更强,已经不能简单视其为一种架构风格,而是可以称为一套软件设计的基础平台了。它拥有领导制定技术标准的组织 Open CSA;有清晰软件设计的指导原则,譬如服务的封装性、自治、松耦合、可重用、可组合、无状态,等等;明确了采用 SOAP 作为远程调用的协议,依靠 SOAP 协议族(WSDL、UDDI 和一大票 WS-*协议)来完成服务的发布、发现和治理;利用一个被称为企业服务总线(Enterprise Service Bus,ESB)的消息管道来实现各个子系统之间的通信交互,令各服务间在 ESB 调度下无须相互依赖却能相互通信,既带来了服务松耦合的好处,也为以后可以进一步实施业务流程编排(Business Process Management,BPM)提供了基础;使用服务数据对象(Service Data Object,SDO)来访问和表示数据,使用服务组件架构(Service Component Architecture,SCA)来定义服务封装的形式和服务运行的容器,等等。在这一整套成体系可以互相精密协作的技术组件支持下,若仅从技术可行性这一个角度来评判的话,SOA 可以算是成功地解决了分布式环境下出现的主要技术问题
“更系统”
“更系统”指的是 SOA 的宏大理想,它的终极目标是希望总结出一套自上而下的软件研发方法论,希望做到企业只需要跟着 SOA 的思路,就能够一揽子解决掉软件开发过程中的全部问题,譬如该如何挖掘需求、如何将需求分解为业务能力、如何编排已有服务、如何开发测试部署新的功能,等等。这里面技术问题确实是重点和难点,但也仅仅是其中的一个方面,SOA 不仅关注技术,还关注研发过程中涉及到的需求、管理、流程和组织。如果这个目标真的能够达成,软件开发就有可能从此迈进工业化大生产的阶段,试想如果有一天写出符合客户需求的软件会像写八股文一样有迹可循、有法可依,那对软件开发者来说也许是无趣的,但整个社会实施信息化的效率肯定会有大幅的提升。
微服务是一种通过多个小型服务组合来构建单个应用的架构风格,这些服务围绕业务能力而非特定的技术标准来构建。各个服务可以采用不同的编程语言,不同的数据存储技术,运行在不同的进程之中。服务采取轻量级的通信机制和自动化的部署机制实现通信与运维。 - - 《凤凰架构》
“将应用程序构建为松藕合、可独立部暑的一组服务”是“微服务架构设计模式”一书中对于微服务架构的定义,但是不管用什么语言去描述微服务架构,它的本质其实是一种“架构风格”,这一点是需要我们牢牢记住的。
微服务架构的核心思想就是“服务”,所谓“服务”,其实指的是项目中的功能模块,它可以帮助用户解决某一个或一组问题,在开发过程中表现为 IDE(集成开发环境,例如 Eclipse 或 IntelliJ IDEA)中的一个工程或 Moudle。举个例子(来自“微服务架构设计模式”):下图是订单服务的外部视图。订单服务具有API ,为其客户端提供对功能的访问。有两种类型的操作:命令和查询。API 由命令、查询和事件组成。命令如 createorder ()执行操作并更新数据。查询,如findorderById()检素数据。服务还发布由其客户端使用的事件,例如OrderCreated
而且微服务架构风格天然就符合“松耦合”的设计原则,在微服务架构中服务之间的交互采用API 完成,这样做封装了服务的实现细节。这允许服务在不影响客户端的情况下,对实现方式做出修改。松藕合服务是改善开发效率、提升可维护性和可测试性的关键。小的、松藕合的服务更容易被理解、修改和测试。通过API 来实现松耦合服务之间的协调调用,避免了外界对服务的数据库的直接访问和调用。
而对于微服务更多的细节介绍本文直接引用“凤凰架构”中对于Martin Fowler 与 James Lewis 合写的文章《Microservices: A Definition of This New Architectural Term》九个核心的业务与技术特征的解读:
至此,对于微服务架构我们已经有较为完善的认识,如果想了解更多的细节可以去看看马丁·福乐写的《Microservices: A Definition of This New Architectural Term》 。
🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺
最后,我们再来思考“SOA架构和微服务架构之间的关系”问题。这个就留给大家自己思考,希望大家看完本篇文章可以找到这个问题的答案!!
🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺🤺