微服务使用各个子服务控制模块的思想代替SOA中的总线。服务控制模块通常至少包含：服务注册与发布、路由、代理。
微服务与SOA的对比
- 目的：
- SOA强调异构服务之间的协作和契约，强调有效集成，最大化应用程序服务的可重用性；
- 微服务的目的是拆分解耦应用，专注去耦合，让不同不同的业务团队服务不同的微服务，专人专事，缩小迭代影响范围，让微服务更容易进行
水平扩展；微服务遵循单一职责，是一种克服系统复杂性的分解技术。如果你觉得你的某个微服务很复杂，那么考虑看看是否拆分的不够细？也正是因为这种拆分，本质上增强了安全性和故障隔离；
- 部署方式：
- SOA服务不多，一般打包后直接通过war形式部署到服务器；
- 微服务由于数量众多，需要实现快速扩容和缩容，一般借助容器化技术来实现部署，微服务之间独立部署，互不影响；
- 服务粒度：
- SOA对粒度无要求，通常是粗粒度的，更强调的是接口的规范化；
- 微服务提倡进行细粒度的拆分，保证服务职责的单一。
| SOA | 微服务 | |
|---|---|---|
| 服务粒度 | 粒度较粗 | 细粒度拆分 |
| 部署难度 | 需要重新创建或者部署整个应用 | 每个微服务可以独立构建部署 |
| 通信开销 | 大部分业务模块在一个应用里面，通信开销低 | 更多的远程调用，增加了通信开销 |
| 存储 | 一般所有服务共享数据存储 | 每个可以拥有单独的存储 |
| 业务易上手 | 需要了解整个应用的业务，上手较难 | 单服务上手容易，但是服务集群理解比较难(复杂度守恒定律：业务复杂度不会因为迁移到了微服务而降低) |
| 通信方式 | SOA体系结构依赖于消息传递（AMQP，MSMQ）和SOAP作为主要的远程访问协议，协议偏重量级； | 使用轻量级协议，如HTTP/REST |
| 可扩展性 | 难以扩展 | 使用容器技术很方便扩展 |
1、微服务的优势
1.1、方便扩容与保证服务可伸缩性
正是因为微服务的拆解，让我们增加了系统的安全性和故障隔离，可以让我们针对不同的服务，实施不同的扩容和存储技术。
例如，一些微服务可能使用关系数据库，而另一些可能使用NoSQL数据库甚至挂载的文件系统。以这种方式构建应用程序增加了团队构建应用程序的可伸缩性。
1.2、降低耦合，利于团队协作与版本快速更新
在SOA系统，或者是传统的单体系统中，使用一个项目的时候，通常会有一个大团队的人在同一个项目的同一个分支上工作，并且总是互相干扰，出现各种代码冲突，随着代码增长，开发速度会呈现指数级增长。这是我们以前遇到过的问题，特别头疼，后来花了很大的精力对系统做了服务化改造拆分。
当然主导这个服务化改造也是需要申请不少资源的，即使没有新的业务上线。为了让老板认为我们正在做的改造是存在价值的，当时还写了改造前后的各种利弊对比。这是很重要的，我们总不能无故的去改造一个运行良好的系统。
有了微服务架构，应用程序由小型分散的开发团队构建，这些团队独立地工作和更改微服务。
1.3、服务自治
这使得测试和升级服务以及随时间增加功能变得更加容易。
最终，如果一个微服务在规模和功能上增长，它可以被分解并分成多个微服务，从而保持微服务的小型、可管理和自治。
1.4、让项目保持技术多样性
最后，采用微服务体系结构允许使用最适合其开发的任何语言和技术堆栈来编写单个服务。并没有严格的限制所有的微服务都必须使用相同的技术来开发，只要它们都通过相同的轻量级协议(如HTTP和消息)进行通信，并且数据结构以相同的格式进行序列化(JSON是最流行的选择)。
微服务的特点是:
- 轻量级的组件；
- 服务独立的部署能力；
- 轻量级、粗粒度api；
- 轻量级的服务总线；
- 轻量级的数据存储；
1.5、避免了单体系统开发效率低下的问题
单体系统要么是数据库变得太大了，要么是代码行太多了，更有可能的是，现在的开发人员不能快速地添加新特性。微服务体系结构避免了单体系统的缺陷，使用真实且可靠的分解技术来解决这些缺陷，并将重点放在敏捷开发和可替换性上，而不是可重用性上。
此外，与单体系统不同，微服务是一个可持续的体系结构，通过添加新的微服务来满足快速变化的业务需求，而不是修改(和破坏)旧的服务。
2、微服务面临的问题
没有什么架构是免费的
尽管微服务有很多好处，但它并不是万能的。微服务在减轻整体应用程序固有的许多问题的同时，也带来了其他挑战。与技术领域的任何事情一样，总是需要在不同的体系结构和微服务之间进行权衡。
2.1、增加了运维的复杂度，以及维护微服务集群的复杂度
它所提供的敏捷性和开发速度是以增加操作复杂性为代价的，因为自然有更多的活动部件(或服务)—可能比单体应用还要多。
使用微服务架构可能会增加运维开销。 使用这种方法，您的部署可能需要大量资源。您可能需要更多的时间和精力来创建基础架构。 所有服务可能都需要群集以实现故障转移和弹性。 您的系统可能具有数十个单独的组件，并且在您添加新功能时，它将变得越来越复杂。
您可能会得到一个由20或30个或更多服务组成的解决方案，而不是一个整体系统，每个服务都运行多个进程。
最佳实践是，您应该通过DevOps自动化解决这些额外的工作开销。
2.2、单体系统迁移到微服务比价困难
**把单体系统迁移到微服务也是一个巨大的工作量。**不推荐用微服务重写系统，这不太现实，特别是单体系统业务比较复杂的时候。建议采用一种更渐进的方法，逐步地重构一个单体系统，逐渐地将它转变成一个由微服务组成的“新”应用程序。随着时间的推移，单体应用程序实现的功能数量会减少，直到完全消失或变成另一个微服务应用程序。最后，不要觉得有必要立即开始分解一切；花时间和工作在最合理的方式为你的团队。
2.3、提高了开发的技术门槛
在开始实际的迁移过程之前，我们得思考权衡以下问题：可以肯定的是，具有微服务体系结构的系统提供了大量的好处，例如独立部署、强大的子系统边界和技术多样性。
但是，因为微服务是一个分布式系统，它带来了开发分布式应用程序相关的复杂性的代价，如：独立的数据模型、微服务之间的弹性通信、最终一致性和操作复杂性等。开发和运行大规模的分布式服务也不是一件容易的事情。
在实际的把单体系统拆分为微服务的过程中，**不建议用服务大小来衡量拆分效果，而是拆分的业务边界，可以考虑使用DDD的方式去进行建模设计。**DDD是我们架构师工具箱中用于标识和设计微服务的优秀工具。
3、微服务技术体系
微服务需要关注的点很多，下面画了一张图来表述：
总的来说，微服务MSA架构需要以下技术点的支持：
- 配置管理；
- 服务发现和负载均衡；
- 弹性和容错；
- API管理；
- 服务安全；
- 日志管理；
- Metrics监控；
- 分布式调用链追踪；
- 调度和发布；
- 自动伸缩和自愈；
除了技术相关的，组织结构和团队文化也是很重要的。
下面是一般微服务涉及到的各种组件：
