微服务是干什么的
我对于微服务最大的体会就是：对于云平台来说，如果元数据驱动的平台组件是骨骼，那么微服务和触发器就是串联骨骼的经络和血脉没有经络和血脉，一堆组件仅仅是静态的，不能变化，没有反馈，更何谈交互。而一个PaaS平台可以孵化无数个SaaS应用，每个应用都需要使用一套小服务来开发，而为了防止应用搭建复杂化和避免后期难以维护，所以每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP AP（Rest的方式，这就是为什么我能看到那些标签的存在）。好处体现在以下方面：
- 这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署（体现在平台就是微服务站点部署和独立微服务站点部署）
- 这些服务可以使用不同的编程语言实现（只要实现结果，无所谓编程语言，这是我认为现在平台没有充分使用到微服务的地方，也可能是我平时使用其它语言的业务场景较少）
- 这些服务可以使用不同数据存储技术（“非结构化数据和结构化数据都可以按需存储”）
- 这些服务可以保持最低限度的集中式管理（这个厉害了，相当于接口不仅可以在一个项目里复用，甚至在不同项目间复用）
微服务的特性
- 每个微服务可独立运行在自己的进程里，一系列独立运行的微服务共同构建起了整个系统
- 每个服务为独立的业务开发，一个微服务一般完成某个特定的功能，比如：订单管理，用户管理等（我用于图书管理系统和工单中心）
- 微服务之间通过一些轻量级的通信机制进行通信，例如通过REST API或者RPC的方式进行调用（这就是Rest标签的由来吧，是一种通信机制）。
微服务的特点
- 易于开发和维护。由于微服务单个模块就相当于一个项目，开发这个模块我们就只需关心这个模块的逻辑即可，代码量和逻辑复杂度都会降低，从而易于开发和维护。（部署独立mrest站点，启动迅速，代码量小）
- 启动较快，这是相对单个微服务来讲的，相比于启动单体架构的整个项目，启动某个模块的服务速度明显是要快很多的。（回收应用程序池即可，不到1分钟搞定）
- 局部修改容易部署,在开发中发现了一个问题，如果是单体架构的话，就需要重新发布并启动整个项目，非常耗时间，但是微服务则不同，哪个模块出现了bug只需要解决那个模块的bug就可以了，解决完bug之后，只需要重启这个模块的服务即可，部署相对简单，不必重启整个项目从而大大节约时间。（有了bug直接hotfix这部分的ESB的interface）
- 技术栈不受限，比如订单微服务和电影微服务原来都是用java写的，现在我们想把电影微服务改成nodeJs技术，这是完全可以的，而且由于所关注的只是电影的逻辑而已，因此技术更换的成本也就会少很多。（虽然目前还没有接触到多语言技术扩展，但感觉这个很强）
- 按需伸缩，单体架构在想扩展某个模块的性能时不得不考虑到其它模块的性能会不会受影响，对于微服务来讲，完全不是问题，电影模块通过什么方式来提升性能不必考虑其它模块的情况。
