微服务的优缺点

微服务架构优点

• 松耦合
• 抽象
• 独立
• 应对用户需求的多样性
• 更高的可用性和弹性
• 代码可理解性
• 调试效率
• 可以应用不同的技术栈
• 容易重构
• 可以定义不同的硬件环境（IO密集型，计算密集型)

微服务架构缺点

• 可用性降低：远程调用
• 处理分布式事务较棘手
• 全能对象（God Classes）阻止业务拆分：如电子商城应用中的订单几乎涉及电商应用中的每一个业务
• 学习难度曲线加大：需要掌握一系列的微服务开发技术
• 组织架构变更

如何进行微服务架构设计

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

微服务粒度

粗粒度优先，逐步拆分
最好的方式是先专注于各个服务之间的交互，先把它们划分成粗颗粒度的服务，然后随着系统的升级和功能的提升，再将这些粗颗粒度的服务逐渐细化，形成更为合理的微服务粒度。
反之，如果所设计的微服务颗粒度太细，一个明显的标志就是每一个微服务几乎都需要和其他的微服务进行沟通，每个微服务只承担其中很少量的业务处理，然后就交给其他微服务处理，造成了一个外部请求需要经过太多的微服务才能够完成处理。当你想单拎出一个服务时，发现几乎不可能，因为每一个微服务都依赖于其他微服务，同时又被其他微服务所依赖。

微服务拆分原则

• 单一职责原则
• 共同封闭原则

微服务自治原则

一个团队越大，那么沟通与协助成本就会越高。因此，在微服务治理中有一个重要的理念就是自治，自治范围并不只是代码和数据，还包含微服务的运行和维护管理，所以亚马逊的微服务有一个规则：你构建，你运行。
每个微服务拥有其业务领域对象下的数据，只有该微服务可以对这些数据进行操作（包含读取与更改），而其他微服务只有通过该服务才能访问到这些数据，不能直接通过数据库进行沟通。因此，我们可以不用为每一个微服务创建一个独立数据库，可以将它们统一存放在一个数据库中，保障不破坏上述的数据访问原则即可。

微服务交互原则

• 使用REST协议
• 使用URI表达
• 使用JSON数据格式
• 使用HTTP标准状态码

不适合微服务的场景

• 构建分布式架构非常吃力时；
• 服务器蔓延时；
• 采用小型应用、快速产品原型时；
• 对数据事务的一致性有一定要求时。