一、微服务的概念

微服务架构可以说是如何将功能分解成一系列服务的一种架构模式。对于一个应用系统包含两部分的需求：第一部分是功能性需求，用于定义一个应用是用来做什么的，该应用系统用来达到什么目的；第二部分就是非功能性需求，包括了对应用系统的扩展性、灵活性，还有性能、运维、安全、测试、监控等需求，这种非功能性需求是用来保障业务系统能够正确、顺畅地运行。而对于微服务架构来说，则着重于后一种需求。

总而言之，微服务核心思路就是分而治之。

对于微服务中的服务可以这么理解：服务是一个可以独立运行、提供范围有限的功能（可以是业务功能，也有可能是非业务功能）的组件。功能具体实现隐藏在组件内部，而对外则提供访问接口，外部其他服务可以通过这些接口进行访问与交互，从这一方面来说，微服务是可以单独部署运行的。

二、微服务的优缺点

优点：
松耦合：降低影响范围
抽象：一个微服务对其数据结构和数据源拥有绝对控制权
独立：每个微服务可独立编译、打包和部署
应对用户需求的多样性：可快速实现需求并部署上线
更高可用性和弹性：每个微服务都可以随时上线或下线，可快速扩展

缺点：
可用性降低：远程调用不稳定
分布式事务难处理：调用多个微服务时数据一致性问题
学习难度曲线加大
组织架构变更：整个应用的部署复杂，包括服务编排、关联关系、回滚计划等，都需要协调不同的团队

三、如何进行微服务架构设计

简单来说可分为下面三个步骤：
第一步，把应用中关键的需求定义出来；
第二步，识别出采用微服务架构时应用中所包含的所有服务；
第三步，将第一步所定义出的关键需求作为架构需求的场景来描述服务之间如何进行协作。

1. 微服务粒度
对于设计微服务来说，最好的方式是先专注于各个服务之间的交互，先把它们划分成粗颗粒度的服务，然后随着系统的升级和功能的提升，再将这些粗颗粒度的服务逐渐细化，形成更为合理的微服务粒度。

2.微服务拆分原则
1）单一职责原则（SRP, Single Responsibility Principle）
降低业务之间的耦合，保持微服务的业务单一性

2）共同封闭原则（CCP, Common Closure Principle）
将业务上联系紧密的服务组织在一个微服务中，当业务发生改变时可限制修改范围

3）微服务自治原则
谁构建，谁运行。每个微服务拥有其业务领域对象下的数据，只有该微服务可以对这些数据进行操作（包含读取与更改），而其他微服务只有通过该服务才能访问到这些数据，不能直接通过数据库进行沟通。即使不分库，也要准守该原则。

4）微服务交互原则
需要规范交互方式，包括rest协议、URI表达、JSON数据格式、状态码。

3. 微服务架构迁移
与大规模进行重构相反，在进行微服务架构迁移时可以使用Martin Fowler提出绞杀（Strangler）模式。在迁移时应首先围绕着传统应用开发出新的微服务应用，并逐渐替代传统应用中的部分业务功能。通过这种方式逐步构建微服务应用，并替代、兼容整合旧的传统应用，直到微服务承担全部应用功能，而传统单体架构应用此时也就可以退出历史舞台了。

4. 不应使用微服务架构的情形
1）构建微服务架构非常吃力时；
2）服务器蔓延时；
3）采用小型应用、快速产品原型时；
4）对数据事务的一致性有一定要求；

四、微服务架构的核心关键点

参考：
《Spring Cloud微服务架构开发实战》-董超，胡炽维