Java架构师系统架构设计服务拆分

---

想学习架构师构建流程请跳转：Java架构师系统架构设计

1 服务拆分和子系统模块拆分

相关文章

软件架构思想和系统架构图:https://blog.csdn.net/ZGL_cyy/article/details/126414922
医疗管理系统-检查项管理：https://blog.csdn.net/ZGL_cyy/article/details/111924782
互联网大型网站的特点：https://blog.csdn.net/ZGL_cyy/article/details/129221855

本章的主要内容是解决高层架构设计的一个难点，就是服务拆分落到项目上就是订单系统的服务拆分。那在这章呢我们首先会学习服务是什么，服务有什么样的基本要求。然后咱们先去学习服务拆分的基本方法，接下去再学子系统和模块拆分的方法。
随着互联网的迅猛发展和业务需求的不断变化，传统的单体应用架构逐渐暴露出扩展性、维护性和部署灵活性等方面的瓶颈。为了应对这些挑战，越来越多的企业和团队开始采用服务化架构，将应用拆分为独立的服务，从而实现更高效、灵活和可扩展的系统设计。

1.1 服务化架构的优势

模块化和解耦合： 通过将应用拆分为多个服务，可以实现模块化开发，不同服务之间解耦合，从而降低了代码的复杂性。
灵活部署： 每个服务可以独立部署，无需整体发布应用。这使得团队可以更频繁地进行部署，快速响应业务需求。
可扩展性： 根据业务需求，可以针对性地扩展特定的服务，而无需对整个应用进行扩展，从而实现更好的性能和资源利用。
技术多样性： 不同的服务可以采用不同的技术栈，根据需求选择最合适的技术，使团队能够更好地应对多样性的业务问题。
团队协作： 团队可以并行开发不同的服务，每个团队负责一个或多个服务，提高了团队协作效率。

2 描绘系统蓝图里面的详解服务

确定系统边界里面都已经确定好了。那这个时候就等于说我们把视角把它从外部转向系统内部。那么这个时候当我的视角进到系统内部的时候，就需要对系统内部的这些功能进行一个划分。到底我这个系统应该分成多少个子系统？同样道理，当我这个视角继续进入到每一个子系统的时候。比如说进到用户管理，那么这个时候呢跟这儿画的一样，那我又会去划分出这个子系统下面又包含哪些子系统或者哪些模块。也就是说我们需要对业务进行这样一层一层的拆分，这就是咱们所说的服务的拆分。
那么这一块呢也是很多新手架构师啊犯错的地方。也有一部分架构师呢把这个服务的合理拆分制作是一个难点。
但事实上啊这一块特别简单。那我们一起来看一下。

服务是什么？这里所说的服务，其实呢我们就可以把它看作是一定功能级的聚合封装体。我先写出来，服务就是一定功能级。
的。封装体。大家一看这个熟啊，以前是不是就讲过了。前面我们就讲从设计的角度来看，像什么组件啊、模块啊、子系统啊、系统啊等等的都是一个概念，都是用来封装一定功能的封装体。那这里的服务也是一定功能级的封装体。
从这个角度来看，这个服务本质上是不是就类似于我们的什么组件啊、模块啊、子系统啊、系统啊这样子的呢？
没错，这里提的服务就可以类比为我们以前讲的组件模块，这些概念并不一定特指微服务，这一点大家注意一下。

2.1 为什么拆分服务

就是因为现在微服务架构比较盛行。但是服务的本质其实就是一定功能级的封装体。所以说这个地方啊大家要从设计的概念去理解，它并不一定是微服务。可以呢类比为。咱们学过的啊，像组件呢。模块啊、子系统啊、系统啊等等。也就是说呢，我们是从系统设计的角度，或者是从设计思维上来看待服务。那么服务的本质就是一些功能集合的这么一个封装体。比方说内部的子系统啊、模块啊、组件啊等等的进行划分。当然本质上就是对这些功能进行聚集，然后把这些相关的功能集啊进行聚合封装。这就是我们这儿所说的服务。所以说按照这个概念来讲啊，我们这儿划分的用户管理是一个服务，商品管理是一个服务，订单管理还是一个服务。那么当我的视角再次进入到某一个子系统里面，比方说进入到用户管理里面，那大家看就到这里了。

子系统实际上它里头又有一堆的功能，怎么办呢？我就要对这一堆的功能进行重新的划分聚集，然后形成不同的封装体，这个就是新的服务。那么咱们就这样一级一级的分下去，这个做的就是服务的拆分。

3 服务拆分的基本要求

3.1 服务功能是自包含的

所谓自包含啊，它指的就是一个服务所需要的功能，应该尽量都包含在自己这个服务之内，这就叫自包含。就是你要实现一定的功能，那么你需要的这些东西呢都在自己这个福字内，这种情况就叫做自包含。应该尽量。
包含在这个服务内部。当然啊从绝对意义上说，完全的自包含你肯定是做不到的。

虽然说每一个服务都是一个封装体，但是呢这个服务啊还是要去跟其他的服务，或者是跟外部的第三方系统去进行交互。
其实呢就跟咱们这儿画的这图是一个道理的。所谓自包含就比如说你用户管理里面要实现用户管理的功能，那么尽可能的他所需要的这些东西呢都在内部。但是也不一定是百分之百的都包含在它的内部。像咱们这画的这个，你看它还可能有部分功能需要使用外部第三方系统crm来提供。对的吧。所以说呢绝对意义上的自包含是很难的，但我们要尽可能的做到自包含，这就跟我们做设计啊，大家耳熟能详的那句话是一样的。我们应该加强内聚松散耦合。那对服务来讲，功能的自包含。
其实就是加强内聚的一种体现。就说我这个服务它包含很多的功能，那我尽量加强内聚，需要的东西尽量都在我服务内部解决，是不是就是体现了加强内聚的这么一个思想。

3.2 服务呢应该具备独立性和专业性

独立性和专业性。

这个独立性呢指的就是一个服务应该加强内聚功能上独立啊，这是一个意思。另外一个呢就是服务能够独立的部署，独立的运行，这呢是服务独立性的另外一层含义。这个地方稍微写一下。就说一个体现。
服务。应该加强内聚。其实就跟。第一条讲的是一样。就从整个功能级上来看，它是独立的。这是一个。
那么另一个呢。就是能够。独立部署。独立运行，那么这两个含义就是独立性的意思。

再来理解一下专业性。专业性呢它指的啊就是按照垂直专业的方式来聚合功能就是按照。垂直。专业的方式来聚合功能。
那这个呢最典型的比如说搜索服务。你看这个大家一听就知道，这是一个非常专业的功能。那么我们可以把它单独出来，也就是把搜索相关的功能划分到同一个服务。类似的比如说支付服务，那就可以把跟支付相关的这些功能包装成为一个服务等等的这是按照垂直专业的方式来聚合功能。当聚合出来的产物就是咱们这儿所说的服务。那再看看第三的一个服务之间应该松耦合。那我们到这儿再来写一下第三的一个。其实这些啊跟咱们前面讲类的设计是很类似的。咱们一直在提要加强内聚松散耦合。
前面呢已经提到了服务应该加强内聚，那这一条呢就来告诉我们服务之间应该松散耦合，其实道理是一样的。
大家看这个图，如果我们的这个服务之间呢有很多的联系，服务之间耦合度越高，那么未来我这个系统变化的可能性就会越小变化的难度就会更大。我们也说过，从设计的角度看，你一个组件和一个类，从某种意义上说都可以画等号。
就好比我这一个功能小到一个类呀，我这个用户管理里面就一个类，可以的吧。

所以说呢从某种意义上说，这个服务和这个服务之间的关系不就演变成了这里头一个类这里头一个类类和类之间的关系了吗？
因此，他一样要遵循加强内聚松散耦合这样子的指导思想。好，我们到这儿来，服务之间应该松耦合。这一条呢就是告诉我们一个服务内部的变化呀，不能够影响到调用服务的客户端，也就是服务之间应该是松散耦合的。这样的话我们就可以随时对服务进行升级或者是切换不同的服务的实现了。

3.3 服务是无状态的

这里呢首先大家理解的是状态，所谓状态就是指数据。那么说服务通常是无状态，那就没数据吗？
不是，是指的在服务端不为客户端保存数据，这叫无状态。那么目前来说呢，大家在设计上已经形成了一个共识，就是在服务端这边不会去保留客户端的数据，也就是说呢服务是无状态的。那么这样一来的话，不管哪个客户端调到服务端都是一样的执行功能。那这个呢就是要求我们服务要做到无状态。无状态服务（stateless service）对单次请求的处理，不依赖其他请求，也就是说，处理一次请求所需的全部信息，要么都包含在这个请求里，要么可以从外部获取到（比如说数据库），服务器本身不存储任何信息

有状态服务（stateful service）则相反，它会在自身保存一些数据，先后的请求是有关联的

有状态服务常常用于实现事务（并不是唯一办法，下文有另外的方案）。举一个常见的例子，在商城里购买一件商品。需要经过放入购物车、确认订单、付款等多个步骤。由于HTTP协议本身是无状态的，所以为了实现有状态服务，就需要通过一些额外的方案。比如最常见的session，将用户挑选的商品（购物车），保存到session中，当付款的时候，再从购物车里取出商品信息
有状态服务可以很容易地实现事务，所以也是有价值的。但是经常听到一种说法，即server要设计为无状态的，这主要是从可伸缩性来考虑的。如果server是无状态的，那么对于客户端来说，就可以将请求发送到任意一台server上，然后就可以通过负载均衡等手段，实现水平扩展。如果server是有状态的，那么就无法很容易地实现了，因为客户端需要始终把请求发到同一台server才行。

3.4 服务之间采用轻量级的通讯机制

采用轻量级的通讯机制。这个主要是指当我拆分了服务过后，这些服务呢又会在分布式的环境下去运行。那么服务之间完全隔离开了，在运行的时候他们之间的相互调用怎么办呢？
就一定要有通讯机制。那目前来说主流的通讯机制主要就两大块，一个呢应该说是一类吧。
就是以http或者说是https。加上restful风格的接口。那么传递的数据呢，另一类就主要是走rpc。远程过程调用，比如说像double这些东西。那么上面这个呢，比如说spring cloud。等等等。

4 服务拆分的基本方法

业务拆分： 识别应用中的业务功能，并将其拆分为独立的服务单元。每个服务应专注于一个具体的业务领域。
定义接口： 定义服务之间的接口和通信协议。通常使用HTTP、RESTful API等方式进行通信。
数据管理： 考虑数据的存储和管理方式。每个服务可以拥有自己的数据库，或者共享数据库，根据业务需求选择最合适的方式。
部署和运维： 设计部署和运维策略，确保每个服务可以独立部署，并能够实现监控、日志和故障恢复。
通信和协调： 考虑服务之间的通信方式，如同步调用、异步消息等。需要确保服务之间的协调和一致性。

对于服务的拆分呢有很多的方法，那咱们这里呢会去讲它的六大方法。那我们先来看一看。第一的一个就是按业务边界拆分。
那大家一看啥叫按业务边界呢？我写到这儿来啊。想想咱们前面讲的有确定系统边界

4.1 按业务边界拆分

呢，就是利用这个结果，你看天然的就可以把我们这个系统啊，假如说拆分成微服务的话，做成用户管理的微服务、商品管理的微服务、订单管理的微服务。

4.2 按业务功能进行横向和纵向的拆分

首先呢大家理解什么是横向拆分，什么是纵向拆分。所谓横向拆分就是按照不同的业务领域或者说是专业性来进行拆分。
比如说：按业务领域我们可以把系统分成。像刚才咱们这个用户管理、商品管理、订单管理。这其实就是一个业务领域，就是按照不同的业务来进行拆分。比如说把我这个系统按照业务你看是不是拆分成了多个服务，这呢是一种横向拆分。
还有一种呢就是按照专业的角度来进行拆分。比如说咱们这里头涉及到搜索服务、支付服务、统计服务等等的那我们就应该把这些也拆分成单独的微服务，那这种拆分呢就叫做横向拆分。

那什么叫做纵向拆分呢？纵向拆分是在横向拆分的基础之上，对每一个微服务啊进行更细粒度的划分。比如说我们这个地方已经划分出了商品管理作为一个微服务，但是呢我觉得它太大了，所以说我想要把它进行纵向拆分。可能呢根据咱们的业务归集，又把它拆分成为实物商品服务、虚拟商品服务、福利商品服务等等的。也就是说把一个服务我可能又分成了四个服务，这个就叫做纵向服务。但是大家注意啊，纵向服务拆的这些服务也一定要符合咱们前面讲的服务的那些要求。不能说把其中的某一个步骤拆分成为多个步骤，每个步骤作为一个微服务，一般来说是不会这么做。比如说有人认为我的订单处理服务服服务十几个步骤，那我能不能把这每一个步骤。做成一个独立的微服务呢？这是不可以的那你想想如果把每个步骤做成一个微服务的话，你想想之间的交互关系，相互之间的依赖。所以说呢那种纵向拆分是不可取的，咱们还是要从业务功能的聚集上去进行拆分。

4.3 按服务分层拆分

实际上分层这个事儿啊大家非常的熟悉。比方说咱们前后端服务分离，这本身就是一种分层拆分的形式。
单纯从后端上来讲，也可能会拆分成很多层。比如说可能会有一个专门的层次来为前端服务。从服务架构的角度来讲呢，通常称这层为聚合服务。比如说咱们这个系统提供给系统平台管理人员使用的一些功能，单纯从服务的实现上，它可能分散到了很多的微服里面。但是为了跟前端配合，那我们通常就会专门聚合出一个服务。把所有跟系统平台管理人员相关的一些功能都聚合到一起。所以说我们把这样子专门为前端服务的，通常称之为聚合服务。那么聚合服务这一层又会向下去调用咱们真正的业务服务。
而业务服务下面可能又有公共的基础的一些服务做支撑。大家想想这样是不是就自然的形成了服务的分层拆分。

4.4 性能进行服务的拆分

按照前面的方法，我们拆分的服务过后可能会发现呢某些服务啊性能上达不到要求。那么我们可能会进一步来拆分服务以满足性能的要求。举个简单的例子，比如说我们系统里面原来有促销这一块。那在促销里面呢，有一种促销方式叫做秒杀。
原本呢就是做在这一个服里头的这没问题啊，挺好的。但是后来呢随着这个业务的发展，那么参与秒杀的人越来越多，发现呢放到这个促销里面已经支撑不住了，满足不了秒杀的这个性能要求。

那咱们就把秒杀系统从这个促销服务里面独立出来，把它形成一个单独的微服务。那么这样的话，我就可以在秒杀系统里面来对它进行高并发啊，高可用等的处理。这种情况呢就是为性能进行服务拆分。这个呢我们也可以到这边接着来示范。比方说。这样他脱下来。这是第四的一个。为性能进行服务的拆分。

4.5 安全进行服务拆分

那我们就可以上面这一个，你看啊把它先选上。长在。拖一个出来。还得再往下挪点。那这个里面我们就可以把一些公共的超长安全的服务，可能就有一些公共的安全的服务，比方说账号授权和鉴权。就是一个安全管理的微服务。当然这个我既可以做成一个微服务，那同样的还有风控系统啊什么的了。

4.6 复用服务拆分

就是说当我们在进行细节实现思考的时候啊，就可能会发现在很多个微服里面都需要提供相同的功能。那这种情况下，我们肯定要把这些相同的功能拆分出来，形成独立的公共的服务，以供这多个服务使用。这其实啊跟咱们发现多个类里面有相同的这个方法，或者是类似的功能实现的时候，我们就会把它提炼出来，做到公共的模块里去，形成自己的什么util啊或者是公共负类啊等等的是一样的道理。如果说这些功能跟业务不相关的话，我们可能还会进一步把它们封装的基础服务里去。那这些都是为了重用而进行服务拆分的方式。当这个呢在咱们这儿其实就不太好表现。

因为我们这儿呢有一个所谓的公共功能的微服务，那这个怎么来的呢？就是你在实现上面这些微服的时候，或者在思考他们的时候，发现他们有一些公共的功能需要抽取。那我们是不是都可以往这里头搬？暂时是这样。当然你的公共功能的微服务如果特别庞大或者说特别庞杂，那你也可以按照功能对它进一步拆分成不同的微服务。那这个呢，咱们这儿就先不多说了。那这呢我先把它收上去，这样刚刚好呢，咱们在一屏里能看到。总之呢通过咱们前面讲的这些方法，大家会发现我们对一个系统能够很容易的把它划分成为很多很多的微服务。所以说划分微服这件事儿并不是那么困难。当然前提就是你前面的需求分析，还有确定系统边界，这些事情做的比较好，对业务理解比较深刻。划分微服务其实是一个水到渠成的事情。因为你对业务理解比较深刻，所以说你就知道这个功能该包在哪些服务里头，就它跟谁是聚合在一起的。因为这每一个服务就是一定功能级的聚合体嘛。而考虑你的功能到底该划分到哪一个微服务的时候，其实就咱们前面讲的还是一样高内聚低耦合。你看看把它放到哪一个里头，业务功能更完整，更能体现高内聚低耦合，那就把它放到那儿非常的简单好了。

5 子系统和模块拆分的方法

前面呢我们已经学习了服务拆分的基本方法，模块拆分的方法呢和前面服务拆分的方法是类似的。只不过咱们常规意义上认为子系统啊、模块啊，它们的功能范围要比咱讲的服务会更小一些。其实咱们前面讲那个服务呢，主要还是针对系统级别。

5.1 按业务功能进行聚合拆分

实际上咱们前面做服务啊，也是按照业务功能进行聚合的。只不过呢那个过程啊不是在拆分的时候来聚合，而是咱们在前面进行需求分析，还有进行确定系统边界的时候，就已经把它聚合好了。

但是子系统模块拆分呢在前面可能做的没有那么细，那这个时候呢就需要我们自己来按照业务功能进行聚合。
那啥叫按业务功能进行聚合呢？稍微说一下。这就是一个模块啊。因为我们前面也讲过从设计的理念看，模块本质上还是一定功能的封装体嘛。那只不过我这个模块里头到底放哪些功能呢？那我们尽量把同一个主体的这个功能放到一起，那我就形成一个模块了。

比如说吧把用户管理里面跟用户账号相关的这些功能聚合起来，我们就可以形成用户账号管理模块。
可能我们前面确定系统边界的时候，我们只确定到了这儿是用户管理这么一个大的子系统。那么在用户管理里面又有哪些小的子系统，或者说分成哪些小的模块呢？就需要我们自己按照这个业务功能来进行聚合了。
那就像刚才讲的，我就可以做出一个用户账号管理的这么一个模块。
类似的把跟用户信息相关的一些功能聚合起来，就可以形成用户信息管理模块。
你看这就是按照同一主体。这个同一主体啊就是说大家说的或者是描绘的是同一一个业务，那么把这些东西呢放到一起，那就形成模块了。还是比较简单的。

5.2 颗粒度进行子模块的拆分

它指的啊就是说咱们前面通过功能聚合拆分出来了很多子模块。那么拆分之后呢，我们发现某些模块功能还是比较多。
那我们就要考虑一下是不是还可以进一步的拆分。也就是说要根据这个封装的颗粒度，那里面封装的功能太多，我们可以来想办法把它再拆细一点。比如说前面提到的用户信息管理模块，那现在你去一看，发现里面功能太多了，还可以继续向下拆分。
比如说把用户的基本信息拆分成为用户基本信息管理模块。那么跟用户教育经历相关的拆分成为用户教育经历信息管理模块。
把跟用户工作经历相关的。拆分成为用户工作经历管理模块等等等。

这就是啊按照聚合的范围，还有封装的颗粒程度，再次进行子模块的拆分。当这个呢就要看里面功能的多少，如果觉得多了，那么你可以继续以一个比较小的维度继续拆分。再看第三的一个，根据模块封装的功能所起的作用来进行分层拆分。
其实前面讲服务拆分的时候也提到了分层拆分。那这儿呢其实跟那个非常类似，到这稍微写一下，就分层拆分的时候。大概是这样。如果这些模块的功能啊是公共使用的那你可以把它拆到基础层，就这个模块是公共使用。那么一般来说啊，这种我们把它拆到基础材料。

6 总结

服务拆分这一块呢，有些人觉得它很困难，最主要的呢就是不知道这个服务拆多大它是比较合适的。也就是他很难把这个服务的边界定出来。那具体的呢我们去实战一下，看看到底该怎样进行服务的拆分。事实上这个服务拆分呢方法上来看还是非常简单的那回顾回顾这是咱们前面讲的一些基本方法，最主要的还是按照业务边界来进行拆分。也就是说服务的聚合本质上是业务的聚合，你把相同的相近的或者为了完成同一件事情所形成的这些功能聚合到一起，它就能够自然而然的形成服务。
当然啊按照咱们前面讲的，从设计的角度来看，所谓服务系统、子系统、模块、组件等等，他们都是能完成一定功能的封装体。
从本质上来讲是一样的，只不过规模上有大小。常规意义上我们认为像服务就类似于像子系统或者说是系统。它的范围比较大。
那么一个服务里面可能又包含很多子系统，子系统下面又分很多模块，每个模块下面可能也有很多组件等等的这只是咱们常规意义上的一个划分，但是本质上它们是相通的。所以说呢咱们这里再谈服务的划分，也可以连带的去把子系统模块划分一块都做了。事实上呢子系统模块拆分的这些方法跟服务拆分的方法也是大同小异的。最根本的都是按照业务来进行拆分。那么除了按照业务来进行拆分之外呢，还有一些其他的。比如说为了线缆进行服务的拆分，为了安全进行服务的拆分，还有呢为了重用进行服务的拆分等等的。你把这些服务替换成子系统，替换成模块，这个逻辑是一样成立的那我就不去多说了。而这些方法咱们前面都讲过。

本章我们来学习架构设计服务拆分和子系统模块拆分这章的服务就是一定功能级的封装体，并不一定是微服务，可以类比为组件、模块、子系统、系统等等的概念。更多的呢我就不具备大家的服务以及我们学习的服务的基本要求。
比如说是服务功能是自包含的，服务应具备独立性和专业服务之间呢应该是是双耦合的，服务通常是无状态的，还有服务间采用

1 拆分的时候，咱们在确定系统边界的时候要注意这个度，一般建议呢不超过三层。
2 划分微服务的时候，咱们要注意力度的大小，尽量呢是大力度的让服务之间的这个交互关系尽量要少学完了服务拆分的方法过后，接着引申咱们就去学习了子系统和模块拆分的方法，则有按照业务功能进行聚合拆分。第二种呢是按照功能聚合的范围和封装颗粒度进行子模块的拆分。
3 一种呢是根据模块封装的功能所起的作用来进行分层拆分。
4 是为重用进行模块拆分等等的内容。