前面说了单块架构的不足，那么微服务又是何方神圣？具有什么样的特性？以下是摘自马丁.福勒先生博客中的描述：
微服务架构是一种架构模式，它提倡将单一应用程序划分成一组小的服务，服务之间相互协调、相互配合，为用户提供最终价值。每个服务运行在其独立的进程中，服务与服务间采用轻量级的通信机制互相沟通（通常是基于HTTP的RESTful API）。每个服务都围绕着具体业务进行构建，并且能够被独立地部署到生产环境、类生产环境等。另外，应尽量避免统一的、集中式的服务管理机制，对具体的一个服务而言，应根据业务上下文，选择合适的语言、工具对其进行构建。
用不同的语言、技术和工具来实现不同的服务；各个服务自成一派，但服务之间又互相配合，最终形成一个有机整体为客户提供价值；这种体验想想就让人流口水！
那么问题又来了，既然要把系统功能拆分为一个个的“微服务”，那么这个“微”的标准又是怎样的呢？
虽说代码量或重写时间可以在一定程度上界定“微的程度”，但个人还是认同以“业务独立性”和“团队自主性”来作为微服务的划分标准。毕竟作为一个服务提供者，如果甚至都不具备业务独立性，那不论是从业务逻辑的清晰程度还是从业务执行效率来看都会大打折扣的。“团队自主性”原则建议团队人数不超过10人，否则沟通和协作上耗费的成本会显著增加。而且，团队应该由不同技能、不同角色的成员组成，是一个全功能的团队。
对于“全功能团队”的建设个人观点还是很有必要的。就现在而言，多数企业应该还是以技能来划分团队，将一群技术栈类似的人分到同一个团队，然后一个业务需求过来需要从各个不同的团队中调取相应的“技术池资源”来配合完成。像这种人员组织的方式，常常会导致沟通成本较大，协调效率较低的情况，而且最重要的还是各个开发人员对于本次业务仅仅是当成一次“任务”而已，没有更进一步将它当成自己的“作品”。开发人员对于自己所写的代码缺乏“主人翁精神”，团队成员对产品也缺乏成就感。
微服务架构的主要特性有以下几点：
1. 单一职责：对于每个服务而言，在服务架构层面遵循单一职责原则。符合高内聚、低耦合，不同的服务通过“管道”的方式灵活组合，从而构建出庞大的系统。
2. 轻量级通信：服务之间应通过轻量级的通信机制，实现彼此间的互通互联，相互协作。所谓轻量级通信机制，通常指语言无关、平台无关的交互方式。对于微服务而言，通过使用轻量级通信机制，使服务与服务之间的协作变得更加标准化，也就意味着在保持服务外部通信机制轻量级的情况下，团队可以选择更适合的语言、工具或者平台来开发服务本身。
3. 独立性：在单块架构中，功能的开发、测试、构建以及部署耦合度较高，相互影响。而在微服务架构中，每个服务都是一个独立的业务单元，当对某个服务进行改变时，对其它服务不会产生影响。无论是从开发、测试还是部署这些阶段来看，服务与服务之间都是高度解耦的。
4. 进程隔离：所有的功能都运行在同一个进程中，就意味着，当对应用进行部署时，必须停掉当前正在运行的应用，部署完成后，再重新启动进程，无法做到独立部署。但在微服务架构中，应用程序由多个服务组成，每个服务都是一个具有高度自治的独立业务实体。通常情况下，每个服务都能运行在一个独立的操作系统进程中，这就意味着，不同的服务能非常容易地被部署到不同的主机上。
由上述特性可知，微服务架构其实是将单一的应用程序划分成一组小的服务，每个服务都是具有业务属性的独立单元，同时能够被独立开发、独立运行、独立测试和部署。
