随着领域驱动设计、持续交付、按需虚拟化、基础设施自动化、小型自治团队、大型集群系统这些实践的流行，微服务也应运而生。
1、什么是微服务
微服务就是一些协同工作的小而自治的服务。
内聚性：“把因相同原因而变化的东西聚集到一起，而把因不同原因而变化的东西分离出来”。
微服务将这个理念应用在独立的服务上。根据业务的边界来确定服务的边界。
服务越小，微服务架构的优点和缺点也就越明显。使用的服务越小，独立性带来的好处就越多。但是管理大量服务也会越复杂。
自治性：一个微服务就是一个独立的实体。它能够独立部署，也可以作为一个操作系统进程存在。服务之间均通过网络调用进行通信，从而加强了服务之间的隔离性。这些服务应该可以彼此间独立进行修改，并且某一个服务的部署不应该引起该服务消费方的变动。
2、微服务的好处
（1）、技术异构性
在一个由多个服务相互协作的系统中，可以在不同的服务中使用最合适该服务的技术。尝试使用一种适合所有场景的标准化技术，会使得所有场景都无法得到很好的支持。
微服务也可以帮助我们更快地采用新技术，如果你真的可以在两周内重写一个微服务，那么尝试新技术的风险就降低了很多。
（2）弹性
弹性工程学的一个关键概念就是舱壁。如果系统中的一个组件不可用了，但并没有导致级联故障，那么系统的其他部分还可以正常运行。服务边界就是一个很显然的舱壁。在单体系统中，如果服务不可用，那么所有的功能都会不可用，对于单体系统而言，可以通过将同样的实例运行在不同的机器上来降低功能完全不可用的概率，然而微服务系统本身就能够很好地处理服务不可用和功能降级的问题。
（3）扩展
庞大的单体应用只能作为一个整体进行扩展。即使系统中只有一小部分存在性能问题，也需要对整个服务进行扩展。如果使用较小的多个服务，则可以只对需要扩展的服务进行扩展。
（4）简化部署
在微服务架构中，各个服务的部署是独立的，这样就可以更快地对特定部分的代码进行部署。如果真的出了问题，也只会影响一个服务，并且容易快速回滚，这也意味着客户可以更快地使用我们开发的新功能。
（5）与 组织结构相匹配
微服务架构可以很好地将架构与组织结构相匹配，避免出现过大的代码库，从而获得理想的团队大小和生产力。
（6）可组合性
在微服务架构中，根据不同的目的，人们可以通过不同的方式使用同一个功能，在考虑客户如何使用该软件时这一点尤其重要，微服务架构系统会开放很多接口供外部使用。当情况发生改变时，可以使用不同的方式构建应用。
（7）对可替代性的优化
使用微服务架构的团队可以在需要时轻易地重写服务，或者删除不再使用的服务。
3、面向服务的架构
SOA（Service-Oriented Architecture，面向服务的架构）是一种设计方法，其中包含多个服务，而服务之间通过配合最终会提供一系列功能。一个服务通常以独立的形式存在于操作系统进程中。服务之间通过网络调用，而非采用进程内调用的方式进行通信。
微服务架构是实现面向服务架构的一种特定方法。
4、其他分解技术
（1）、共享库
这是一个非常标准的分解技术，不同的团队和服务可以通过库的形式共享功能。但这种方式的缺点是：无法选择异构技术，一般这些库只能在同一种语言中使用。因为共享的原因，会失去独立对系统某一部分进行扩展的能力。
（2）模块
模块分解技术，允许对模块进行生命周期管理，这样就可以把模块部署到运行的进程中，并且可以在不停止整个进程的前提下对某个模块进行修改。
OSGI（Open Source Gateway Initiative，开放服务网关协议），是一种模块分解技术，OSGI的问题在于它非常强调诸如模块生命周期管理之类的事情，但语言本身对此并没有足够的支持，这就迫使模块的作者做更多的工作来对模块进行适当的隔离。在一个进程内很容易使模块之间过度耦合，从而引起各种问题，OSGI带来的复杂度要远大于它带来的好处。
Erlang采用不同的方式，模块的概念内嵌在Erlang语言的运行时中，因此这种模块化分解方式是很成熟的。它的确定与共享库类似，即它会大大限制我们采用新技术和独立对服务进行扩展的能力，并且有可能会导致使用过度耦合的集成技术，同时缺乏相应的接缝来进行架构的安全性保护。
5、没有银弹
微服务也不是解决所有问题的银弹，选择微服务也要面临分部署系统需要面对的复杂性，如果为了得到微服务带来的好处，同样需要在部署、测试和监控等方面做很多的工作。