微服务化后，一个项目的架构图如下所示：

微服务拆分的原则

单体化的项目就像一个大的蜘蛛网，不同模块交织在一起，调用比较复杂，一个问题出bug可能会导致连锁的问题。所以要对架构进行拆分。而进行拆分则需要遵循以下原则：

1、做到单一服务内部功能的高内聚和低耦合

也就是说每个服务只完成自己职责之内的任务，对于不是自己职责的功能交给其它服务来完成。

拆分初期可以把服务粒度拆得粗一些，后面随着团队对于业务和微服务理解的加深，再考虑把服务粒度细化。

要一边做产品功能迭代，一边完成服务化拆分。拆分只能在现有一体化系统的基础上不断剥离业务独立部署，剥离的顺序你可以参考以下几点：

优先剥离比较独立的边界服务（比如短信服务、地理位置服务），从非核心的服务出发减少拆分对现有业务的影响
当两个服务存在依赖关系时优先拆分被依赖的服务。比如内容服务依赖于用户服务获取用户的基本信息，那么如果先把内容服务拆分出来，内容服务就会依赖于一体化架构中的用户模块，这样还是无法保证内容服务的快速部署能力。

服务拆分之后，由于服务是以独立进程的方式部署，所以服务之间通信就不再是进程内部的方法调用而是跨进程的网络通信了。在这种通信模型下服务接口的定义要具备可扩展性，否则在服务变更时会造成意想不到的错误。

微服务会引入一定的复杂度：

1、服务接口调用不再是同一进程内的方法调用，而是跨进程的网络调用，这会增加时延，同时接口调用方需要知道服务部署在哪些机器的哪个端口上，这些信息需要存储在一个分布式一致性的存储中，于是就需要引入服务注册中心。

2、多个服务之间有着错综复杂的依赖关系。一个服务会依赖多个其它服务也会被多个服务所依赖，那么一旦被依赖的服务的性能出现问题产生大量的慢请求，就会导致依赖服务的工作线程池中的线程被占满，依赖的服务也会出现性能问题，有可能会导致整个服务崩溃。

为了避免发生这种情况，我们需要引入服务治理体系针对出问题的服务采用熔断、降级、限流、超时控制的方法，使问题被限制在单一服务中，保护服务网络中的其它服务不受影响。

3、服务拆分到多个进程后，一条请求的调用链路上涉及多个服务，那么一旦这个请求的响应时间增长或者是出现错误，我们就很难知道是哪一个服务出现的问题。

另外，整体系统一旦出现故障，很可能外在的表现是所有服务在同一时间都出现了问题，你在问题定位时很难确认哪一个服务是源头，这就需要引入分布式追踪工具，以及更细致的服务端监控报表。