微服务架构和SpringCloud实践总结（二）

演进过程

首先梳理了所有的产品线的业务逻辑，这次改造完全针对的是Java栈的业务产品线，包括有友邻计划，邮包，友两手（友邻计划因为需求排期的原因没有在阶段进行拆分）。对业务逻辑和数据进行重新的设计，规划和拆分，最后形成大概三个主要类型的服务，包括基础服务，业务服务和监控服务。另外除了这些服务外，新上线的业务会全部使用Spring Cloud这套技术栈。

基础服务。基础服务我们定义为业务服务所以依赖但又和具体的业务无关的服务。例如：OAuth服务，推送服务，基础数据（用户和房屋）服务。这些服务相对来说比较容易从原有的业务系统中分离出来，也是我们最先确认并分离的服务。

业务服务，主要是与各业务相关的服务，例如商品服务，订单服务，是一些垂直的业务系统，每个拆分出来的服务只处理单一的业务类型。

监控服务。虽然这部分相对独立。独立的部分主要在于监控系统最后的前端的信息展示。而对于每个服务的监控信息收集的部分在架构设计初期就做好了技术准备。所以在每个服务具体的实施过程中，已经实现了对于监控信息收集部分的内容。不过最终的系统呈现出来的内容是在业务上线后才进行落实的。

拆分步骤

在技术选型和预演完成之后。梳理每个独立的业务系统，确定每个系统改进行服务拆分类型，拆分的后数据结构，已确认拆分过程的节奏和进度。

团队成员熟悉Spring Boot / Spring Cloud，优先开发基础服务，通过基础服务的开发积累技术框架的使用经验。

改造项目的顺序根据业务的复杂程度由易到难进行推进，邮包，友两手，友邻市集。是一个经验积累的过程。

实际的改造过程中是一个这样的过程：基础服务，邮包相关的业务服务，监控服务，友两手相关的业务服务。之所以加了邮包和友两手中间开发了监控服务，是因为已经具备了监控服务的开发条件，同时监控服务和友两手的业务服务可以并行开发。这样在友两手上线后就可以看到监控数据。由于微服务的架构是在一个业务场景中会存在多个服务的调用，所以系统监控的服务尽可能有业务上线的第一时间就可以使用。

拆分原则

横向拆分。按照不同的业务领域进行拆分，如订单，商品服务

纵向拆分。例如APP调用服务，后台管理服务。

服务分层，区分核心服务和基础服务，将这些服务沉到整个架构的底部，保证稳定性，为上层服务提供稳定的服务。

服务内部高内聚，服务之间低耦合。

在拆分的过程中我们也发现并不是拆的越小越好，过小的服务会带来更高维护成本和代码量，具体的拆分粒度还是需要与具体的业务相结合。

数据库遇到的问题

数据库的线上切换。由于拆分微服务的过程中对数据库也进行了拆分，而原有的业务一直处于线上状态，随时都会有新的数据进来。这样就无法保证两边数据的一致性。解决方案有两个：

准备好数据切换脚本，在切换的时候停掉原有业务后执行数据切换脚本。这种方案带来的问题是需要确保数据切换脚本准确无误，前期需要预演多次保证切换过程的顺利无误。

改动原有业务系统或者创建一个监听程序，在完成原有业务的数据写入之外，将新来的数据按照新的数据结构写入一份。

第一个方案适合业务简单的场景，数据量较小的场景。较大的数据量和复杂的业务都会导致业务停机时间过长，需要保证业务停机在合理的承受范围之内。第二个方案虽然实施过程相对复杂，但相对于第一个方案来说在能够降低服务在切换的时候风险。

联合查询的问题。例如展示邮包列表中的用户信息，按照之前拆分的邮包信息和用户信息被拆分到两个服务中，拥有相对立的数据库。方案如下：

在邮包列表中对用户信息进行冗余

在获取邮包列表中的记录是调用用户服务获取邮包信息

使用实时或者准实时的将数据同步到NoSQL类型的数据库中，在同步的过程中进行数据清洗，用于前端的查询

方案一适合数据实时性不高的业务，方案二需要对用户服务进行一些额外的处理，例如加入缓存，提高服务的响应性能。方案三是比较适合大型的高并发场景。

总结

团队的技术人员需要适应这种开发模式，传统模式的开发每个开发人员通常是一个人一个模块的开发，而现在是一个人开发一个系统，需要具备微服务的思想，对技术人员提出了更高的要求。

Spring Cloud非常适合快速实现微服务架构体系的建立，完善的微服务技术生态圈可以使用大部分的场景，大大减少了开发成本。但是要注意并不是每一种该技术方案都需要用上，适合实际的业务需要才是最重要的。

在服务拆分后会形成众多的服务，对于服务的部署带来的新的挑战，这个是容器化技术就显得尤为重要。后面会专门写一篇SpringCloud与Docker实现自动化部署的文章详细介绍