传统的 SOA 概念其实是个比较粗放、面向功能接口地说法，更多地强调的是大型服务系统中间关系，包括服务发现协议、服务权限控制等等，跨企业通讯的意思浓厚。但是微服务更像是 Object+Task 任务控制一样，往往强调的组织内部并发高性能的对象是高效率高并发和简单化地部署在一起的，实际上更强调地是那种依赖于传统的高速缓存机制优化的系统的分布式计算。由于性能高了成百上千倍，所以一个网络上可能存在相同功能的几十万个微服务并且自动路由，而不是传统的简单 SOA 设计者以为的那几个功能服务，而是几十万几百万的对立对象的服务。比如说针对某档案馆系统，传统的 SOA 可能是指粗放地简单的 api 接口，而微服务是指这个档案馆的几百万档案每一个都可以独立看成是一个服务——假设一个档案服务没有创建那么微服务系统就会瞬间创建一个新的微服务实例。SOA 的概念可以看成是初学者脑子中的那种“面向过程”的东西，过程访问数据时是通过什么“调用数据库驱动增删改查”来操作的。而微服务可以看成是电信级系统的“面向对象”的东西（类似过去的 Remoting 概念），过程访问数据是通过访问它本地缓存数据、或者访问其它微服务来编程而不是什么数据库增删改查。当然当你集成多种简单系统时，完全可以把微服务技术与传统 SOA 应用结合起来。他们不是对立的，而是从 SOA 逐步演化到微服务架构的。
一个好的微服务管理系统，自身就应该是一个“调度总线”，它可以瞬间创建一个服务，也可以自动回收那些闲置了很久的服务。就好像上面的“档案馆微服务系统”例子一样，它不是说提供几个什么 api 功能调用接口，而是说它自身就能提供几十万、几百万动态创建和动态收缩的服务对象。
不是说你用 asp.net 之类的写个什么 webapi 服务然后部署上去，就说“我部署了一个微服务”了。实际上微服务系统是一个网络操作系统层面的东西，它可以注册几百、几千台服务器，然后自动创建、收缩、承载几亿、几百亿服务对象，并且自动将针对某个服务对象的操作路由到正确的机器和线程上去。你可以提交一个 dll，然后注册 dll 中你的服务对象到这个操作系统上。网络就好像人的大脑，单个大脑也是由无数的计算机组成的。因为有了广义的网络操作系统模型，才有了细微的服务。不是说传统地发布个什么 asp.net 服务就叫做微服务。
传统地，你让几个不同的部门自己用 asp.net 写了几个“服务”部署上去，集成在一起（一台或者多台服务器上），告诉用户说“我们用SOA 架构”。但是微服务是个高性能的网络操作系统，部署和撤销服务应该比传统的 SOA 方式更自动化、更快何止千倍万倍，相当于你过去客户端是针对业务服务器接口和它（们）背后的数据库服务器来操作，现在你的客户端可以针对几千万上亿的“对象云”来直接操作。比如说过去你查看档案，是访问某个 webapi 接口来输入输出 json 数据，访问是无状态的。现在你是直接获得档案 id 的客户端代理，然后你直接对档案的各个属性和方法进行（貌似）有状态的操作，而云端则会专门配置一个高速的对象服务给你（每一台服务器上都会动态创建几十万档案服务对象）。类似于18年前的 remoting，但是比 remoting 更加面向分布式计算，更加实用。
首先对于应用本身暴露出来的服务，是和应用一起部署的，即服务本身并不单独部署，服务本身就是业务组件已有的接口能力发布和暴露出来的。
其次，微服务架构本身来源于互联网的思路，因此组件对外发布的服务强调了采用HTTP Rest API的方式来进行
微服务的基本思想在于考虑围绕着业务领域组件来创建应用，这些就应用可独立地进行开发、管理和加速。在分散的组件中使用微服务云架构和平台使部署、管理和服务功能交付变得更加简单。