一、
我理解的微服务架构是来源于SOA架构的，但是微服务的接口的密度更小了。如创建Item，会创建出来Item、版本和版本属性表。如果在SOA中，这三个应该在同一个接口中，
但在微服务中，可能会分为创建Item、创建版本、创建属性表三个接口。
这里说SOA易于扩展，但是其实微服务也应该是易于扩展的。
面向云化、移动化；云化，应该是微服务架构更加易于部署到云服务器中，因为微服务的架构是比较轻量级的，而搭SOA架构是比较复杂的。
移动化，应该是像移动端，有些功能是不需要像桌面端那么复杂的，只需要取一个简单的接口，实现简单的功能。。而接口的细分，则不用再重新写接口，
如果像SOA那样的接口涵盖的东西比较多，则可能需要写两套代码，一套是桌面端调用，一套是移动端调用。
二、
我自己的理解是
如果我们开发一个服务，只部署到一台服务器上，如天气预报，访问量比较大的，就会这个服务部署到多台服务器上去，减少并发量
但是这种情况，就会有个问题， 查询天气预报的调用者访问的时候，会遍历每台服务器，先访问服务器1的服务并发量没到限制，则直接访问服务器1的服务，
如果服务器1的服务挂掉了，则访问不到服务
SOA，则相对上述这种服务访问机制的缺陷进行优化，SOA会内置一个治理中心的程序，如果服务1挂掉了，则不会直接访问其他正常的服务器的服务，规避上述访问
不到的情况，
微服务，
1、技术上和SOA的不同
A、内置了很多了在SOA基础上优化的组件
B、如有三个服务创建零组件服务，创建数据集服务，创建流程服务....分别在3台不同的服务器上，但是这3个服务需要部署到1台总的服务器治理中心上（中心化），如果总服务器治理中心挂掉了，则其他服务也无法访问，而微服务是去中心化，虽然微服务也有类似SOA的总的服务器治理中心，但是就算治理中心挂掉了，也可以访问其他服务，并不影响
C、SOA主要采用xml的传输形式，微服务采用http的resultful传输形式，现在后者传输形式更为流行，无论是网页端、App，桌面端基本都是采用这种的，像我们调用sharePoint的接口，就是采用后者的传输形式
2、理念上的不同：
主要是把SOA的服务进行更加细分化，如果我们的创建服务，在SOA我们只有一个创建服务，但在微服务中，可能会细分成创建零组件服务，创建数据集服务，创建流程服务....
如果像SOA一个创建服务，服务挂掉了（实际可能只是创建零组件出问题了），那么创建其他的就都不可以了， 但是在微服务中，创建领部组件服务挂掉了，但创建数据集、创建流程服务还是没问题的可以使用的。