微服务架构设计实践

微服务架构设计实践数据库

目 次安全

1 序言网络

2 微服务架构

3 软件架构设计思想并发

4 微服务架构设计实践负载均衡

4.1 项目概述框架

4.2 架构准备阶段分布式

4.3 概念架构阶段模块化

4.4 细化架构阶段微服务

4.4.1 业务架构

4.4.2 数据架构

4.4.3 应用架构

4.4.4 技术架构

4.4.5 物理架构

4.4.6 开发架构

1 序言

最近,在软件架构设计领域,微服务很是火。

一提到软件开发、架构设计,若是不提微服务,不说说微服务的架构风格,那就落伍了,OUT了。

固然了,支持微服务的技术也是层出不穷,如微服务1.0中比较有名的来自Spring家族的Spring Cloud,以及国内在开源领域的翘楚阿里系中的Dubbo。其中,Spring Cloud提供了完整的微服务解决方案,为开发者提供了快速构建分布式系统的通用模型的工具,包括配置管理、服务发现、熔断器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态等。而Dubbo是一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及服务治理方案。

随着微服务的持续火热,微服务2.0中的ServiceMesh也火起来了。Service Mesh,即“服务网格”,做为服务间通讯的基础设施层,Service Mesh能够被看做是微服务间的TCP/IP,负责服务之间的网络调用、限流、熔断和监控。对于编写服务的开发人员来讲,通常无须关心TCP/IP这一层(好比经过 HTTP 协议的 RESTful 应用),一样使用Service Mesh也就无须关心服务之间的那些原来是经过应用程序或者其余框架实现的事情,好比Spring Cloud、OSS,如今只要交给Service Mesh就能够了。

其实,上述说了那么多,介绍了那么多,基本都是集中在概念层面,在理论的层次上,以及支持微服务的开发技术、开发框架上,缺乏这些概念、理论、技术和框架在实际项目中具体地应用。

对于大多数开发人员、架构师来讲,除了理解微服务相关的概念,熟悉微服务相关的技术和框架,更关心如何在实际的项目中,应用这些概念、技术和框架。而这些,正是如今所欠缺的。

笔者从事软件开发多年,参与和指导过多个项目的架构设计,经历过单体架构、分布式架构、SOA架构,对软件架构的发展历史有必定的了解。

同时,在架构设计过程当中,笔者也拜读了多位架构大师的著做,如温昱老师的《软件架构设计》、《一级架构师》,Peter Eeles和Peter Cripps的《软件架构设计的过程》等,以及各位技术大咖们在互联网上分享的各种架构相关的文档,使我受益不浅。在此,我衷心的对这些前辈们表示由衷的感谢,谢谢大家对于知识的分享,以及无私奉献的精神。

最近,笔者有幸参与了某银行的一个采用微服务架构风格的项目,实践了一下微服务架构。

更确切地说,该项目是分布式服务架构向微服务架构的演进,使用更细粒度的服务和一组设计准则来考虑大规模的、复杂的系统架构设计,并不是一个纯粹的微服务架构风格的项目。

秉着知识共享的精神,笔者写了这篇“微服务架构设计实践”的文章,一方面是对本身在架构设计方面的一个阶段性总结,另外一方面是但愿给其余刚刚从事软件架构设计的人员一个真实的、具体的软件架构过程的实践参考,为他们提供一个完整的实践案例。

在写这篇文章的过程当中,在介绍微服务、软件架构设计思想的概念、方法论时,引用了各位大师、技术大咖们关于微服务、架构设计的文章中的内容,在此衷心地表示感谢。对于引用的内容,笔者并不是简单地摘抄,而是结合笔者的理解和实践,作了适当的调整。若是存在不适、错误的地方,但愿各位及时地指出,我将积极的采纳和修改。

2 微服务

2.1 微服务的定义

微服务是一个独立、可部署的服务,它只专一作一件事情而且作好,而这个事情一般能够是业务能力,或者提供业务价值的最小单元服务。

微服务的描述具备通常服务描述所遵循的内容:

1.使用明确的接口方式,如:WebService、Rest。

2.描述里应该包括约束和策略,如:参数、返回值,以及使用什么通信协议和数据格式等。

微服务中“微”是其独特个性的体现,“微”表示“接口粒度细”。

简而言之,微服务的特征归结为:

1.职责单一,相对独立。

2.接口粒度细。

3.轻量级通信协议。

4.服务之间松耦合。

2.2 微服务架构的定义

James Lewis 和 Martin Fowler 给微服务架构的定义以下:

微服务架构风格指将复杂系统切分为几十甚至上百个小服务,每一个服务负责实现一个独立的业务逻辑。系统中的各个服务一般是独立部署,彼此之间是松耦合的。

每一个服务都运行在本身的进程中,通常采用Rest API风格的轻量级通信协议进行相互通讯。

这些服务围绕业务功能进行构建,经过全自动化的部署方式来进行独立部署。

这些服务可使用不一样的语言来编写,也可使用不一样的数据存储技术,而且基于最低限度的集中管理。

2.3 微服务架构的特征

Martin Fowler 认为,微服务架构具备以下 9 个特性:

1.组件以服务的形式提供。

2.围绕业务功能进行组织。

3.产品而不是项目。

4.强化终端与弱化管道。

5.“去中心化” 地治理技术。

6.“去中心化” 地管理数据。

7.“基础设施” 自动化。

8.“容错” 设计。

9.“演进式” 设计。

2.4 微服务架构的优缺点

微服务架构的优势在于:

1.更加完全的组件化,系统内部各个组件之间解耦的比较干脆,单个系统的规模小不少。

2.能够组建每一个服务独立的维护团队,利于各自团队独立的开发和维护。

3.每一个微服务独立部署,只要服务间的接口稳定,各系统能够相互之间互不干扰的独立发展。

4.微服务架构使得每一个服务自己能够独立的扩展,性能出现瓶颈,优化或增长这个服务的配置便可。

微服务架构的缺点在于:

1.微服务强调了服务大小,但实际上,业界并无给出一个明确的、统一的标准。业务逻辑应该按照什么规则划分为微服务,这自己就是一个经验工程。但要记住,微服务是达到目的的手段,而不是目标。微服务的目标是充分分解应用程序,以促进敏捷开发和持续集成部署。

2.它的分布式特色带来的复杂性。开发人员须要基于RPC或者消息实现微服务之间的调用和通讯,而这就使得服务之间的发现、服务调用链的跟踪和质量问题变得的至关棘手。

微服务架构所面临的挑战:

1.分区的数据库体系和分布式事务。在微服务架构下,不一样服务可能拥有不一样的数据库。CAP原理的约束,使得咱们不得不放弃传统的强一致性,而转而追求最终一致性,这个对开发人员来讲是一个挑战。

2.对测试带来了很大的挑战。对微服务进行测试,须要启动它依赖的全部其余服务,这种复杂性不可低估。

3.对跨多个服务的更改带来的挑战。在微服务架构中,如有A、B、C三个服务须要更改,A依赖B,B依赖C。此时,咱们须要仔细规划和协调每一个服务的变动部署,可能须要先更新C,而后更新B,最后更新A。

4.部署基于微服务的应用也要复杂得多。微服务由不一样的大量服务构成,每种服务拥有本身的配置、应用实例数量以及基础服务地址,这里就须要不一样的配置、部署、扩展和监控组件。此外,咱们还须要服务发现机制,以便服务能够发现与其通讯的其余服务的地址。所以,成功部署微服务应用须要开发人员有更好地部署策略和高度自动化的水平。

基于上述的微服务存在的优缺点,以及微服务架构设计过程当中面临的挑战,建议在软件架构设计时,不要从一开始就以微服务架构做为系统设计的起点。相反地,要用一个单个系统做为起点,并保持其模块化。当这个系统出现了问题后,再将其分解为微服务。

3 软件架构设计思想

3.1 软件架构定义

对于软件架构的定义,仁者见仁,智者见智。目前,业界比较流行的两大流派是组成派和决策派,这两派的概念相辅相成,具体以下:

组成派:软件架构 = 组件 + 交互。

决策派:软件架构 = 重要决策集。

上述两大流派的描述过于抽象,不利于理解,本人更喜欢下述关于软件架构的描述,通俗易懂,即:

软件架构是软件总体结构与组件的抽象描述,用于指导大型软件系统各个方面的设计。软件架构描述的对象是直接构成系统的抽象组件,各个组件之间的链接则明确和相对细致地描述组件之间的通信。在实现阶段,这些抽象组件被细化为实际的组件,好比具体某个类或者对象。在面向对象领域中,组件之间的链接一般用接口来实现。

软件架构是一个用于指导系统实现的草图,这个草图越详细对于系统实现的指导意义越重大,贯穿于软件的整个生命周期。

3.2 软件架构本质

架构的本质就是对系统进行有序化重构,不断减小系统无序的程度,使系统不断进化。

架构从无序到有序的基本实现手段是分和合,即先把系统打散,而后从新组合。

分的过程是把系统拆分为各个子系统、模块、组件。拆分的时候,首先要解决每一个组件的定位问题,而后才能划分彼此的边界,实现合理的拆分。合的过程就是根据最终要求,把各个分离的组件有机整合在一块儿。

分的结果使开发人员可以作到业务聚焦、技能聚焦,实现开发敏捷;

合的结果使系统变得柔性,能够因需而变,实现业务敏捷。

相对来讲,第一步的拆分更难。

3.3 软件架构过程

在这次软件架构设计过程当中,采用了温昱老师在《软件架构设计》一书中说起的ADMEMS方法体系。

ADMEMS方法经过3个阶段和一个贯穿环节,来覆盖“需求进,架构出”的完整架构设计过程。

3.3.1 PA阶段

架构准备阶段是架构设计的第一个阶段,此阶段的工做目标是:理解需求,创建需求大局观,肯定架构设计方向等。

功能需求、质量属性和约束共同决定了架构,对这3类需求的把握是否到位、设计决策是否对路,是软件架构设计的关键所在。

若是可能的话,架构师应该尽早的参与需求分析工做,对需求进行大局的梳理,而不能被动地等待《软件需求规格说明书》的完成。

只要知足如下3个条件,架构师就能够开始架构设计工做:

1.明确的业务需求:甲、乙双方对系统的目标达成共识,《愿景文档》经过了正式评审,而且明确了投资、工期标准、整合等约束条件。

2.全面的用户需求:系统范围明确,即系统能帮用户干什么,不能干什么。

3.典型的行为需求:核心功能的《用例规约》已定义。

在架构准备阶段,经过对软件需求的详细分析,抽取出肯定概念性架构所须要的关键需求。

此阶段的输入是软件需求(即上述的三部分:明确的业务需求、全面的用户需求、典型的行为需求),成果物是肯定的关键需求,包括关键功能、关键质量属性和关键约束影响,做为下一个阶段的输入。

3.3.2 CA阶段

概念架构是对系统设计的最初构想,对大型系统的成功很是关键。

概念性架构定义了系统的高层组件,笼统地界定了高层组件的职责,以及它们之间的关系。

概念性架构主要是对系统进行适当的分解,而不陷入细节。

概念性架构规定了每一个组件的非正式规约及架构图,但不涉及接口细节。

在进行概念架构设计时,必须紧紧抓住重大需求、特点需求、高风险需求,有针对性地肯定解决方案。

关键需求塑造概念架构。反过来,概念架构体现关键需求。

此阶段的输入是关键需求,包括关键功能、关键质量属性和关键约束影响,成果物是针对关键问题的解决策略,和以高层抽象组件方式描述的整个系统的组成草图,能够用在《软件方案建议书》。此成果物做为下一个阶段的输入。

3.3.3 RA阶段

从概念架构到细化架构,先设计概念架构,构思关键问题的解决策略;再进行细化架构的设计,以保证为开发提供足够的指导和限制。

在细化架构阶段,总体设计思路为以分而治之为核心思想的多视图方法。

此阶段的输入是关键问题的解决策略,和以高层抽象组件方式描述的整个系统的组成草图,成果物是描述系统的各类视图,这些视图从不一样的角度,不一样的关注点,描述了抽象的、完整的系统解决方案。

3.4 软件架构视图

多视图方法是业界普遍承认的一种架构设计思路。

一种优秀的多视图方法,应该可以比较完善地覆盖架构设计的各项工做内容,而且将每项工做内容明确地、有理有据地、一目了然地划归到不一样的架构视图中去。

在多视图方法中,每一个视图都从一个思惟角度聚焦一组技术关注点,都从特定角度规划系统的拆分和组合,都是架构的一种体现。

多视图方法种类繁多,其中影响最大的当属由Philippe Kruchten于1995年首次提出的RUP的4+1视图方法,涉及视图分别为逻辑架构视图、运行架构视图、开发架构视图、数据架构视图、物理架构视图。

另外一种在架构设计中常用的多视图方法是联邦企业架构框架(Federal Enterprise Architecture Framework),涉及视图分别为:业务架构视图、数据架构视图、应用架构视图、技术架构视图。

本人所使用的视图方法是以RUP的4+1视图方法和联邦企业架构框架为基础,基于本人在架构设计方面的实践经验,总结出经常使用的6中架构视图,涉及视图为:业务架构视图、数据架构视图、应用架构视图、技术架构视图、物理架构视图、开发架构视图。

为了理论与实践相结合,对于每种视图的介绍放到架构设计实践的细化架构阶段,结合实际的项目,详细描述每种视图。

3.5 架构之间的关系

从根本上讲,架构设计毫无疑问是需求驱动的。因此,软件需求是整个软件架构设计过程的前提条件。

在架构设计过程当中,不一样的架构视图之间并非孤立存在的,它们之间存在着依赖关系,而且这些依赖关系也决定了这些架构视图的设计顺序,具体以下:

1.第一步,根据用户需求肯定业务架构。

2.第二步,根据业务架构,分析、定义数据架构。

3.第三步,根据数据架构,并结合功能需求定义应用架构。

4.第四步,根据数据架构与应用架构来设计技术架构。

5.第五步,根据数据架构、应用架构和技术架构,来设计开发架构。

微服务架构设计实践

 

4 微服务架构设计实践

4.1 项目概述

为了支持分行特点业务在某银行科技整体架构下高效、规范实施,总行构建了分行特点业务云平台,旨在为分行应用提供全面、易用、统1、安全可靠的服务能力,包括业务能力和技术能力,下降对于总行产品模块的接入难度,总体控制接入风险,同时整合、集成总行服务能力。

分行特点业务云平台是一套以总分协同、共享服务体系架构的分行特点业务开发平台。该平台基于行方自主研发的Tesla基础技术框架,实现全分行统1、规范技术支撑架构,为分行应用提供全面、易用、安全可靠的服务。以此为基石,更深、更普遍的发挥全分行科技人员开发能力和对业务支持响应能力。

这次设计的分行特点业务云平台以Tesla平台做为技术载体,采用分布式服务框架理论做为设计依据,在此基础上,构建JAVA版特点业务分平台(JCAP-Java Cloud Application Platform)、服务融合中心(SCC-Service Convergence Center)。

服务融合中心在本次分行特点业务平台的定位是对分行特点业务提供各类总行后台模块的服务能力,而且对分行特点业务的接入作到统一管理和差别化控制功能。

后续的会为你们慢慢补上,努力学习,作一名栋梁之才。

想了解能够私信我!

1 SpringBoot+ 高并发消息处理 EDM?项目 实战

2 SpringBoot ELK?分布式 数据分析

3 Netty?高 并发 UTS?项目实战

4 SpringCloud?微服务+NoSQL+ 负载均衡平台设计