在高扩展问题那一篇说过，微服务是提供系统扩展性的一种手段，那SOA行不行，ESB呢？SOA是一种扩展方式，解决的主要问题是异构系统之间的数据传输问题，适用场景是传统的大型企业内部IT系统，为了不重复建设，适用ESB技术来保证各个异构系统之间，不同协议之间能够进行数据交换，从而达到节约重构系统所带来的成本的目的，SOA更加的是一种架构理念，是从整个企业IT系统角度出发的。而微服务强调的是微，粒度更细，一个子系统就可以进行微服务的划分，划分原则有可能基于业务，或者基于稳定性和非稳定性等，另外其场景更加的是互联网系统，迭代速度要求快，故障隔离要求高，并且要求能够快速交付和部署运维。

实现微服务后，并不是银弹，首先要关注这种架构能够解决的问题是否切合我们的实际需求，另外一个点要看实施微服务架构后的基础设施是否满足，比如，服务发现注册，以及服务容错监控等这些基础设施是否有了，接口通讯是RPC还是HTTP？接口数据格式确定是什么？API网关是否有选型？配置中心，自动化测试和部署这块是否具备？微服务带来的问题也是很明显的，问题难以追踪，链路长，因为系统分散，开发和依赖变得更加复杂，需要上面提到的一些基础实施的支撑。

Runnf这种互联网应用，其特征是完全符合微服务架构的，但是我们在实施的过程中，也是根据实际资源情况有限的进行的。

• 服务的划分粒度

根据团队情况，规模较小，服务粒度不能太细，否则人手不够，核心业务包括用户，轨迹，小组，动态，社交，福利，非核心业务包括不定期举行的活动，合作厂家定制开发，商城，论坛等。基于是否核心业务的划分原则可以保证核心业务的稳定性，让有经验的工程师来负责，而周边子系统可以让一般的来负责即可，但是基于实际情况，将用户，小组，社交划分为一个服务，2个人来维护，而轨迹，动态和福利划分为一个服务，2个人来维护，活动，论坛由1个人维护，论坛单独一个人维护，定制化开发的工作集中力量处理即可。所以具体粒度根据实际情况进行划分。

• 服务发现注册容错

基于新浪微博开源的Motan，提供了微服务的基础功能，即服务的发现注册监控等功能，以及接口选型等，Motan提供了基于zookeeper的服务注册发现机制，以及服务熔断集群等功能，同时Motan是基于RPC机制进行通讯的，这样完全屏蔽了不同JVM之间的调用细节，Motan基于spring的配置扩展机制，非常容易集成到现有系统的spring框架中，另外，Motan也提供了一定的服务治理功能，如负载均衡和熔断机制等。

这些都是微服务实施的基础条件，我们通过第三方开源实现就可以实现了，同时Runnf整体架构上，将后台管理功能也进行了独立部署，包括后台管理库也从核心库中进行了分离。

• API网关

内部服务提供的都是基于业务逻辑的服务API，需要通过统一网关对外提供服务调用，并且保证服务调用的安全机制，流量控制，路由等，所以Runnf的API网关是自研的系统，可以实现外部系统的访问统一分配，包括APP，PC端，以及合作伙伴的访问等。所以网关本身的稳定性就非常重要了，否则会导致服务整体不可用，API网关本身部署也要保证高可用和高性能。

对于Runnf来说，基于以上3个方面的微服务改造完成后，就已经可以做到系统扩展性的要求和工程实施的部分隔离性要求，但是，基于团队资源，自动化部署和运维还不能及时跟上，但是这部分前期可以用人工方式解决，不是核心问题。所以Runnf也是有限的一种微服务的实施，如果按照Spring Cloud的整体架构，还有很多工作需要去完成，合适的就是最好的，没有最好只有更好！