概念
“微服务”一词源于Martin Flower 的Microservices一文，简单的说，微服务是系统架构的一种风格，它的主旨是将一个原本独立的单体系统拆分成多个小型服务，这些小型服务都各自运行在独立的进程中，服务之间通过基于HTTP的RESTful API进行通信。被拆分成的每一个小型服务都围绕着系统中的某一项或一些耦合度较高的业务功能进行构建，并且每个服务都维护者自身的数据存储、业务开发、自动化测试和独立部署。
特性
1. 服务组件化
组件，是一个可以独立更换和升级的单元。在微服务架构中，我们对服务进行组件化拆解。服务是一种进程外的组件，它通过HTTP等通信协议进行写作，而不是像传统组件那样以嵌入的方式协同工作。每一个服务(组件)都独立开发部署，可以有效避免一个服务的修改引起整个系统的重新部署。
2. 按业务组织团队
按传统的方式，我们往往会从技术的层面将团队划分为多个，比如DBA团队，运维团队，后端，前端，测试等。若我们继续按照这种方式组织团队来实施微服务架构开发，当有一个服务出现问题需要更改时，比如简单的在某个实体上增加一个字段，这需要从数据存储开始考虑一直到前端，虽然每个团队的改动都非常小，但这样跨团队的协作会更加消耗沟通成本和时间成本。
在实施微服务架构的时候，需要采用不同的团队分割方法。一般来说，由于每一个微服务都是针对特定的业务实现，既要负责数据库存储，又要负责前端展现。所以按照业务去划分团队，这样既能保证团队的小而精，又能降低沟通成本。
还有一些人建议根据领域驱动设计，推荐阅读《实现领域驱动设计》一书。
【康威定律】 Conway’s law: Organizations which design systems[...] are constrained to produce designs which are copies of the communication structures of these organizations.
（设计系统的组织，其产生的设计和架构等价于组织间的沟通结构。 )
3. 做“产品”的态度
在实施微服务架构的团队中，每个小团队都应该以做产品的方式，对其产品的整个生命周期负责。而不是以项目的模式，以完成开发和交付并将成果交接给维护者为目标。
4. 智能端点与哑管道（ Smart endpoints and dumb pipes）
在单体应用中，组件间直接通过函数调用的方式进行交互协作。而在微服务架构中，由于服务不在一个进程中，组件间的通信模式发生了改变，若仅仅将原本在进程内的方法调用改为RPC方式的调用，会导致微服务之间产生繁琐的通信。所以我们需要更粗粒度的通信协议：
- 使用基于HTTP的RESTful API或者轻量级的消息发送协议，实现消息传递与服务调用的触发。
- 通过在轻量级消息总线上传递消息，类似RabbitMQ等一些提供可靠异步交换的中间件。
4. 去中心化治理
当我们采用集中化的架构治理方案时，通常在技术平台上都会制定统一的标准，但是每一种技术平台都有其短板，这回导致在碰到短板时，不得不花费大力气去解决。
在实施微服务架构时，通过采用轻量级的契约定义接口，使得我们对于服务本身的具体技术平台不再那么敏感，这样整个微服务系统中的各个组件就能针对其不同的业务特点选择不同的技术。
5. 去中心化管理数据
在实施微服务架构中，我们希望让每一个服务来管理其自有的数据库，这就是数据管理的去中心化。
虽然数据管理的去中心化可以让数据管理更加细致，通过采用更合适的技术可让数据库存储和性能达到最优。但是，由于数据存储于不同的数据库实例中，数据一致性也成为微服务架构中亟待解决的问题之一。分布式事务本身的实现难度就非常大，所以在微服务架构中，我们更强调在各服务之间进行“无事务”的调用，而对于数据的一致性，只要求数据在最后的处理状态是一致的即可。
在本人所经历的项目中，澳洲最大的房屋交易网站REA GROUP，为了避免这种数据的不一致性，所有的产品价格只存放在一个数据库中，我们称其为元数据，只有一个组件与对该数据库进行操作，并暴露相应的REST API给其他的外部系统。
6. 基础设施自动化
由于微服务架构中，会有更多的服务需要运维，这使得运维人员需要关注的内容成倍的增长。为了避免该情况的发生，我们必须从一开始就构建起“持续交付” 平台来支撑整个开发过程。该平台需要两大内容，缺一不可：
- 自动化测试： 每次部署前的强心剂。
- 自动化部署： 解放繁琐枯燥的重复操作以及对多环境的配置管理。
7. 容错设计
在单体应用中，一般不存在单个组件故障而其他部件运行正常的情况，一般是一挂全挂。而在微服务架构中，由于服务都运行在独立的进程中，所以很容易出现部分服务出现故障，而其他服务正常运行的情况。
所以在微服务架构中，快速检测出故障源并尽可能的自动恢复是必须被设计和考虑的。
8. 演进式设计
要实现一个完美的微服务架构对一个没有足够经验的团队来说，可能比单体应用付出更多的代价。所以很多时候微服务架构并不是一开始就存在的，而是一步步随着系统的发展，业务的复杂演进而来的。
