廊坊app开发中如何进行服务模块拆分，前面已经讲到了系统高层架构设计落地的第一步，确定系统边界。

接下来具体地看看系统高层架构设计落地的第二步：如何进行服务拆分，这也是很多新手架构师犯怵的地方，一起来看看吧。

一：服务是什么

架构师架构设计：如何进行服务模块拆分（程序员方法经验干货）

这里说的服务，可以看作是一定功能集的聚合封装体，并不一定特指微服务，也可以类比为子系统。

从系统设计的角度，或者是设计思维上，服务的本质就是一些功能集合的这么一个封装体。

因此从设计上来说，系统、子系统、模块、组件等，本质都是一样的，都是一定功能的封装体，只不过功能集的范围大小不一样。

一般我们认为，系统比子系统大，子系统比模块大，模块比组件大，但是从设计层面来看，它们本质都是一样的。

前面讲的确定系统边界，是站在系统外部来看待整个系统，去理解系统要做什么和不做什么，以及系统和相关系统的交互关系等。

当视角从系统外转向系统内部时，首先要做的，就是内部子系统、模块、组件等的划分，其实本质都是对功能进行聚集，然后把这些相关的功能集进行聚合封装，也就是我们这里说的服务。

二：服务的基本要求

1：服务功能是自包含的

自包含的意思就是：一个服务需要的功能，应该尽量都包含在服务之内。

当然，这个做不到绝对，虽然每个服务都是一个封装体，但有些功能，它也需要跟其它服务或外部系统去交互。

因此，只能是尽可能的自包含，就跟我们做设计，耳熟能详的那句话：“加强内聚，松散耦合”一样，对服务来讲，功能的自包含，其实就是加强内聚的体现。

2：服务具备独立性和专业性

所谓独立性，指的是一个服务应该加强内聚，功能上独立；另外一个就是服务能够独立部署、独立运行，这是服务独立性的两层含义。

所谓专业性，指的是按照垂直、专业的方式来聚合功能，比如搜索服务，就是把搜索相关的功能划分到一个服务；又比如支付服务，就是把跟支付相关的功能包装成一个服务，等等的。

3：服务之间应该松耦合

这个大家好理解，简单来说，就是一个服务内部的变化，不能影响调用服务的客户端。也就是服务之间，应该是松散耦合的，可以随时对服务升级，或者是切换不同的服务实现。

4：服务通常是无状态的

这个是目前大家设计上的一个共识，就是在服务端这边，不会去保留客户端的状态（就是指数据），也就是服务是无状态的，不管那个客户端来，都是一样的执行功能。

5：服务间采用轻量级的通讯机制

目前来说，主要是两大派，一派是http/https + Restful 的形式，比如Spring Cloud；另一派主要是RPC，比如Dubbo、Thrift等。

三：服务拆分的基本方法

架构师架构设计：如何进行服务模块拆分（程序员方法经验干货）

1：按AKF进行服务拆分

对于AKF不了解不熟悉的朋友，我们在下一篇来讲述一下AKF扩展立方体。

2：按业务功能进行横向和纵向拆分

所谓横向拆分，就是按照不同的业务领域、或者是专业性 来进行拆分，比如按业务领域把系统分为：用户服务、商品服务、订单服务 等；从专业的角度，分出：搜索服务、支付服务等。

所谓纵向服务，就是在横向拆分的基础上，对每个服务进行更细粒度的划分。比如把商品服务继续细化，拆分成为：实物商品服务、虚拟商品服务、福利商品服务、O2O商品服务等等的。

甚至于商品是来自于第三方系统的，比如来自京东、天猫的商品，可能就要继续拆分出京东商品服务、天猫商品服务等等等。

3：服务分层拆分

比如大家熟知的，前后端服务分离，这本身就是一种分层的拆分形式。

就从后端来讲，可能会有一个层次，是专门来为前端服务的，通常称为聚合服务。

比如给系统平台管理人员使用的一些功能，从服务实现上分散到很多服务里面，但为了跟前端配合，我们通常会专门聚合出一个服务，把所有跟系统平台管理人员相关的功能，都聚合到一起。

聚合服务这一层会向下去调用真正的业务服务实现，业务服务下面又有公共的基础服务做支撑，你看，这样是不是就自然的形成服务的分层拆分。

4：为性能进行服务拆分

如果拆分了服务过后，感觉性能达不到要求，我们可能会进一步拆分服务，以满足性能的需求。

比如秒杀系统，它本来应该是促销服务里面的一部分，但是呢，由于秒杀系统对系统性能要求比较高，会涉及到高并发、高可用等的处理。

所以我们通常会把秒杀系统单独拆分出来，成为一个独立的服务，但对对它进行处理和优化，也把它和业务系统分开，避免因为做活动而把业务系统拖垮。

5：为安全进行服务拆分

这个也比较常见，比如我们考虑到，需要一些公共的授权和鉴权的功能，我们会把账号体系、认证体系独立出来，把它放到网关去进行统一的处理。

又比如跟业务相关的一些安全处理，比如统一的安全管控，控制同一个IP调用的次数、调用的频率、试错的次数 等等的，也会把它们拆分出来，做成一个单独的服务。

进一步，就是对业务的一些风险管控，比如风控系统，也会拆分出来形成单独的服务。

这些都是为了安全进行的服务拆分。

6：为重用进行服务拆分

当我们进行细节实现思考的时候，可能会发现，出现了多个服务都需要的功能，我们就需要把这些功能拆分出来，形成独立的、公共的服务，供这多个服务使用。

这就跟我们发现多个类里面有相同或者类似的功能实现的时候，会把它们提炼出来，做到公共的模块里面去，一样的道理。

如果这些功能跟业务不相关的话，会进一步把它们封装到基础服务里面去。这都是为了重用而进行服务拆分的方式。