将完整的使用本地调用方式的垂直应用拆分成多个微小的服务，每个服务模块负责提供各自独立的服务接口 ，并通过网络调用的方式将各个服务模块组织起来形成完整的微服务系统。
拆分逻辑
系统复杂度：业务的复杂度决定了被拆分的模块之间必然存在一定的依赖，模块被拆分的越细，就意味着会产生更多的依赖关系，在拆分解耦的同时必然增加了整个系统的复杂度。随着业务的丰富不可避免的使系统越来越复杂，所以规范，约定，框架等手段尽量做到结构及代码的清晰与整洁。
团队协作：当垂直应用变得庞大且复杂需要更多的工程师维护时，一般会使用maven的多模块依赖特性将单一的应用拆分成多个模块，每个模块分给不同的工程师维护，最终团队成员提交模块，根据依赖关系打包一个应用发布。
代码维护难度：微服务能够解决在垂直应用中错综复杂的业务逻辑耦合在一起的维护困难问题，但并不是将模块拆分的越细越好，过多的模块反而会增加工作量与代码维护难度。每个模块都处理着属于自己的业务逻辑，他们提供服务并维护者与其他模块的依赖关系，如果服务提供方的返回结果发生变化，则各个调用方均要修改自己的代码。
硬件资源分配：系统存在请求压力不均衡的情况，模块拆分的越细，则能更有针对性的为高压力模块分配更多的计算资源，避免浪费。
单模块：为了设计出低耦合，高内聚的系统，需要确保每个模块都具有一定的独立性，每个模块只完成它所负责的业务功能，并且模块之间做到最少联系及接口简单。单个模块内聚了相关性较强的功能，并且拥有独立 的数据库，单元测试，运行内存，业务逻辑处理等。
大部分请求都是同步的，消费方发起请求后等待提供方完成计算并返回结果，但如果等待的过程过长，则需要借助消息队列与回调将请求的过程变成异步，消费方向服务提供方的消息队列中发送请求消息，服务方计算完成后调用消费方的方法通知结果。
复杂模块：为实现服务业务将基础模块进行聚合重组时，每个模块对自身数据库操作事务的管理比较简单，但基于网络跨模块的二阶事务管理则会将整个过程变得无比复杂，并且消费更多的资源，所以在进行模块拆分时尽量避免二阶事务的产生，无法避免时，可以采用TCC(trying confirming canceling) 补偿性事务解决方案实现。
垂直应用在处理购物车或登陆状态管理等功能时一般会基于session 实现，但在分布式架构下session的共享与传递会增加整个系统的耦合度并且提高复杂性。模块在处理自身业务逻辑及服务调用时，尽量以无状态协议的角度进行社会及，请求玩立刻释放资源。维护状态的工作可由服务提供方增加状态检查的服务，但面对高查询，低修改的场景时可以基于约定交由公共缓存(redis)系统处理
上一篇：https://blog.csdn.net/qq_35781178/article/details/80953914
下一篇：https://blog.csdn.net/qq_35781178/article/details/80961689