微服务架构设计实践

微服务架构设计实践

目 次

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.第五步，根据数据架构、应用架构和技术架构，来设计开发架构。

1、具有1-5工作经验的，面对目前流行的技术不知从何下手，

需要突破技术瓶颈的可以加。

2、在公司待久了，过得很安逸，

但跳槽时面试碰壁。

需要在短时间内进修、跳槽拿高薪的可以加。

3、如果没有工作经验，但基础非常扎实，对java工作机制，

常用设计思想，常用java开发框架掌握熟练的，可以加。

4、觉得自己很牛B，一般需求都能搞定。

但是所学的知识点没有系统化，很难在技术领域继续突破的可以加。

5. 群号：高级架构群 Java进阶群：180705916.备注好信息！送架构视频。

6.阿里Java高级大牛直播讲解知识点，分享知识，

多年工作经验的梳理和总结，带着大家全面、

科学地建立自己的技术体系和技术认知！