服务化资源：
《分布式服务框架原理与实践》
单位的项目目前是个半服务化的方案，实现了以下过程：
服务化
服务治理，提供注册中心
没有使用常用的dubbo这种RPC框架，模拟实现了一个类似的，使用zookeeper做注册中心
服务之间以RPC来相互调用
部分服务提供REST接口
作为微服务来说缺少的部分：
API-GateWay
网关的定位应该是所有请求的入口点。入口点应该实现对api的整理聚合功能、负载均衡功能等等，这部分目前项目是没有的。
手机端访问后台服务的形式
一些思考：
RPC到底有没有必要提供REST接口？
Dubbo没有提供。Dubbox在其基础上提供了REST接口，使用的是EasyRest。所谓框架是服务于业务的，架构的设计会决定框架有没有必要实现一些功能。不直接面对端的服务只是为其他服务提供功能实现，就是传统意义上的RPC，可以不REST，也不该REST。面对端的服务，也许应该实现REST，方便使用，面对端的服务，我们也可以理解它是一个具有MVC架构的消费者，所以他要实现REST其实很简单，SpringMVC完全就可以，然后通过RPC调用不直接面向端的服务。整体架构如下：
譬如，途中OpenService最好是提供REST接口，其实OpenService完全可以是一个WEB应用，具有SSH或者SSM框架，可以接受任何请求的访问，无论是静态页面端还是app端，后台的服务只是为这个OpenService提供支持。途中至于ServiceC和ServiceD要不要提供REST接口，我的观点是：底层服务就不需要了，增加了调试时候的复杂性的同时，也带来了安全隐患。
How to get start?
微服务只是一个概念，具体你可以造车轮，来实现这个概念。目前常见的，两个方向：Dubbo系和Spring Cloud系。入手可以Google这两个东西，会带领你start的。dubbo系我算是比较了解了，Spring Cloud系只是进行了入门了解，感触比较大，从以下几个方面来比较：
A. 上手简单程度： Dubbo简单
B. 功能完善程度： Spring Cloud，Spring跟Netflix结合提供了那么多组件，注册中心有Eureka，API Gateway有zuul，断路器有Hystrix，客户端访问模式有Ribbon和Feign，配置中心有Config Server。想想看，如何使用Dubbox，功能只有注册中心，其余的都需要根据业务自己考虑。
C. 文档完善： Dubbo停止维护了已经，Spring Cloud大有刚刚起势之势头。
D. 其实这么对比他两个是不公平的，参见Dubbo还是Spring Cloud，一个只是一个RPC框架，一个却是一整套解决方案，上述连接对比两者对比的很清楚了。
Spring Cloud
别人讲的非常好，可以参考一下。
Docker与微服务
微服务与Docker感觉就是天生的相辅相成，Spring Cloud参考指南里边也对docker的基础只是进行了介绍，之前博客里对docker有所提及。巨石应用拆分为细粒度的服务，测试，部署，运维都将是一个大麻烦，而docker可以直接将上述环节封装在容器中，实现所谓的Devops。不过目前来看，我个人觉得docker在容器编排方面做得还是不太好，用起来还是不很方便。
服务之间的内部通信
刚才提到了REST，也提到了RPC，其实消息队列也可以实现一些需求，所以在此也需要提及一下Kafka、RabbitMQ等，服务之间通信业可以用这些东西。
