微服务架构设计原则

 

微服务是指开发一个单个小型的但有业务功能的服务，每个服务都有自己的处理和轻量通讯机制，可以部署在单个或多个服务器上。微服务也指一种种松耦合的、有一定的有界上下文的面向服务架构。如果每个服务都要同时修改，那么它们就不是微服务，因为它们紧耦合在一起。

微服务优点:

1. 每个微服务都很小，这样能聚焦一个指定的业务功能或业务需求。

2. 微服务能够被小团队单独开发，这个小团队是2到5人的开发人员组成。

3. 微服务是松耦合的，是有功能意义的服务，无论是在开发阶段或部署阶段都是独立的,单个服务方便扩展。

微服务缺点：

1. 分布式系统难以管理和监控，运维难度加大。

2. 因为分布部署分析和排查问题难度加大。

微服务架构设计原则

1、 服务具有标准的、经过正式定义的、稳定的接口

2、 服务应设计为可重用

（1、设计必须能适应不断增加的吞吐量；如果服务在使用服务的数量增加的情况下仍可成功运行，那么使用率也会成级数递增。

（2、我们必须对服务请求的未来增长进行预计；新使用者可能需要其他的功能，或者需要对现有功能进行更改，服务应该具有高内聚。

3、 服务应具有精心选择的粒度

服务粒度的两个极端——提供仅有几个方法的很多服务，或数十或数百个操作均集中在几个服务中——都将对易用性造成影响。服务粒度过细会导致服务数量的雪崩，一个业务逻辑需要依赖多个服务。服务粒度过粗，容易导致服务升级频繁，可扩展性不高。

4、 服务应是内聚而完整的

（1、我们希望创建功能内聚的服务，一组操作由于其功能相关而聚合到一起。通过使用者的视角，我们会将重点放在服务的功能上。

（2、我们希望服务是完整的。在为已知使用者创建服务时，完整性的问题尤为值得注意。请务必记住，服务应该为可重用的，因此需要考虑将来的使用者的可能需求。举个简单的例子，比如一个服务提供search，add接口，而不提供可能出现的delete接口，除非业务上不会出现delete，否则需要提供该接口达到功能上的完整性。

5、 服务应对实现细节进行封装

服务和接口类似，需要隐藏具体实现细节和逻辑，方便扩展。调用方不要依赖于服务方的具体实现逻辑，服务方实现的改变不应该影响到调用方。

6、 服务是无状态的

有状态的接口存在单点问题，也不方便扩展。服务尽量是无状态的，对于那种必须包含状态的业务，我们可以通过将服务设计为在响应中包含合适的关联信息或者在cookie中存储相关信息，从而避免会话状态。

7、 服务定位和请求路由机制

对服务实现位置的更改应尽可能少地影响客户机。

8、 服务提供多种调用模式

提供同步或异步调用方式供客户端选择。

 

 

 

 

转载于:https://my.oschina.net/iseeyou/blog/719164