glassfish启动后不能进入部署页面_80后程序员用一文带大家深入学习：单块架构如何进化为微服务架构...-CSDN博客

前言

在上一节，我们介绍了分布式系统的常用架构体系。同时，我们也介绍了流行的SOA架构及微服务架构。在对比SOA与微服务的架构时，我们发现，SOA与微服务在很多概念上存在相似点，比如都是面向服务的架构，都是基于HTTP协议来进行通信等。当然，SOA与微服务比较显著的-一个区别在于，SOA代表了“大而全”的风格，而微服务则相反，每个服务都是“小而精”。这种“大而全”的架构，称为“单块架构”。

单块架构的概念

我们的软件系统经常会采用分层架构形式。所谓分层，是指将软件按照不同的职责进行垂直分化，最终软件会被分为若干层。以Java EE应用为例，Java EE软件系统经常会采用经典的三层架构( Three Tier Architecture)，即表示层、业务层和数据访问层，如图1-1所示。

图1-1展示了三层架构中的数据流向。三层架构中的不同层都拥有自己的单一职责。

●表示层(Presentation Layer) :提供与用户交互的界面。GUI (图形用户界面)和Web页面是表示层的两个典型的例子。

●业务层( Business Layer) :也称为业务逻辑层，用于实现各种业务逻辑。比如处理数据验证，根据特定的业务规则和任务来响应特定的行为。

●数据访问层( Data Access Layer): 也称为数据持久层，负责存放和管理应用的持久性业务数据。

如果你仔细看看这些层，你应该看到，每一一个层都需要不同的技能:表示层需要诸如HTML、CSS、JavaScript 等之类的前端技能，以及具备UI设计能力;业务层需要编程语言的技能，以便计算机可以处理业务规则;数据访问层需要具有数据定义语言(DDL)和数据操作语言(DML)及数据库设计形式的SQL技能。

虽然一个人有可能拥有上述所有技能，但这样的人是相当罕见的。在具有大型软件应用程序的大型组织中，将应用程序分割为单独的层，使得每个层都可以由具有相关专业技能的不同团队来开发和维护。

虽然软件的三层架构帮助我们将应用在逻辑上分成了三层，但它并不是物理上的分层。这也就意味着，即便我们将应用架构分成了所谓的三层,经过不同的开发人员对不同层的代码进行了实现，经历过编译、打包、部署等阶段后，最终程序还是运行在同一-个机器的同-一个进程中。对于这种功能、代码、数据集中化，编译成为一一个发布包，部署运行在同一进程的应用程序的架构，我们通常称为单块架构。典型的单块架构应用就像传统的Java EE项目所构建的产品或项目，它们存在的形态一般是WAR包或EAR包。当部署这类应用时，通常是将整个发布包作为一-个整体，部署在同.

一个Web容器中，-般是Tomcat、Jetty 或GlassFish等Servlet 容器。当这类应用运行起来后，所有的功能也都运行在同-一个进程中。

单块架构的优缺点

实际上，构建单块架构是非常自然的行为。我们一-开始启动一个项目的时候，整个项目的体量，一 .般都比较小，所有的开发人员在同一个项目下进行协同，软件组件也能通过简单的搜索查询到，促刀T」刀仅的双个。而上，应的间的，巴脑大还地推山厂叫。

但是，当一个系统的功能慢慢丰富起来，项目也就需要不断地增加人手，此时代码量就开始剧增。为了便于管理，系统可能会拆分为若千个子系统。不同的子系统为了实现自治，它们被构造成可以独立运行的程序，这些程序可以运行在不同的进程中。

不同进程之间的通信，就要涉及远程过程调用了。不同进程之间为了能够相互通信，就要约定双方的通信方式及通信协议。为了能让协同的人之间理解代码的含义，接口的提供方和消费方都要约定好接口调用的方式，以及所要传递的参数。为了减少不必要的通信负担，通信协议一-般采用可以跨越防火墙的HTTP协议。同时，为了能最大化重用不同子系统之间的组件和接口，不同子系统之间往往会采用相同的技术栈和技术框架。

这就是SOA的雏形。SOA 本质就是要通过统一-的、与平台无关的通信方式，来实现不同服务之间的协同。这也是大型系统都会采用SOA架构的原因。

概括地说，单块架构主要有以下几方面的优点。

●业务功能划分清楚:单块架构采用分层的方式，就是将相关的业务功能的类或组件放置在- -起，而将不相关的业务功能的类或组件隔离开。比如我们会将与用户直接交互的部分分为“表示层”，将实现逻辑计算或业务处理的部分分为“业务层”，将与数据库打交道的部分分为“数据访问层”，层次关系良好:上层依赖于下层，而下层支撑起上层，但却不能直接访问上层，层与层之间通过协作来共同完成特定的功能。

●每一层都能保持独立:层能够被单独构造，也能被单独替换，最终不会影响整体功能。比如，我们将整个数据持久层的技术从Hibernate转成了EclipseLink, 但不能对上层业务逻辑功能造成影响。

● 部署简单:由于所有的功能都集合在一个发布包里面，所以将发布包进行部署都较为简单。

●技术单一:技术相对比较单-，这样整个的开发学习成本就比较低，人才复用率也会较高。当然，同时我们也要看到单块架构存在的弊端。

●功能仍然太大: 虽然SOA可以解决整体系统太大的问题，但每个子系统体量仍然是比较大的，而且随着时间的推移，会越来越大，毕竞功能会不断添加进来。最后，代码也会变得太多，且难以管理。

. 升级风险高:因为是所有功能都在一个发布包里面，如果要升级，就更换整个发布包。那么在升级的过程中，会导致整个应用停掉，致使所有的功能不可用。

● 维护成本增加:因为系统在变大，如果人员保持不变的话，每个开发人员都有可能维护整个系统的每个部分。如果是自己开发的功能还好，经过查阅代码，还能找回当初的回忆。但如果不巧的是别人的代码，而且非常有可能代码并不怎么规范，这就导致了维护变得困难。

项目交付周期变长:由于单块架构必须要等到最后-个功能测试没有问题了，才能整体上线，这就导致交付周期被拉长了。这就是“水桶理论”，只要有一个功能存在短板，整个系统的交付就会被拖累。

●可伸缩性差:由于应用程序的所有功能代码都运行在同一个服务器上，将会导致应用程序的扩展非常困难。特别是，如果你想扩展系统中的某-一个单一功能，但你不得不将整个应用都水平进行了扩容，这就导致了其他不需要扩容的功能浪费。

监控困难:不同的功能都杂合在了-一个进程中，这就让监控这个进程中的功能变得困难。

正是由于单块架构的缺陷，伟大的架构师提出了微服务的概念，期望通过微服务架构来解决单块架构的问题。

如何将单块架构进化为微服务

正如前面的内容所讲的，一个系统在创建初期倾向于内聚，把所有的功能都累加到-一起，这其实是再自然不过的事情。也就是说，很多项目初始状态都是单块架构的。当随着系统慢慢壮大，单块架构也变得越来越难以承受当初的技术架构，变更无法避免。

SOA的出现本身就是一-种技术革命。它将整个系统打散成为不同功能单元(称为服务)，通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的、与平台无关的方式进行定义的，所以它能够跨越不同的硬件平台、操作系统和编程语言。这使构建在各种各样的系统中的服务可以以一一种统一和通用的方式进行交互，这就是SOA的魅力所在。

当我们使用SOA的时候，我们可能会进一步思考，既然SOA是通过将系统拆分来降低复杂度的，那可否把拆分的颗粒度再细一点呢? 将一个大服务继续拆分，成为不同的、不可再分割的“服务单元”时，也就演变成为另外一种架构风格一微服务架构。所以，我们说微服务架构本质上是-种SOA的特例。图1-2展示了SOA与微服务之间的关系。

《三国演义》第一回曾说: “话说天下大势，分久必合，合久必分。’软件开发也是如此，有时我们讲高内聚，就是尽量把相关的功能放在一-起，方便查找和使用;有时候，我们又要讲低耦合,不相关的东西之间，尽量不要存在依赖关系，让它们独立自主最好。微服务就是这样演进而来的，当一个系统过于庞大时，就要进行拆分，如果小的服务又慢慢增大了，那就再继续拆分，如同细胞分裂一样。

当然，构建服务并不只是-一个“拆”字了得，我们先来了解下构建微服务的一些原则。

今天给大家讲述的单块架构如何进化为微服务架构的内容，喜欢的朋友，可以转发关注一下小编！！！

下一篇给大家分享微服务架构的设计原则的内容。

感谢大家的支持！！

20年架构师带你深入SpringCloud微服务架构：传统软件行面临挑战