架构设计：微服务架构如何划分？这6个标准原则让你一目了然

互联网应用架构：专注编程教学，架构，JAVA，Python，微服务，机器学习等领域，欢迎关注，一起学习。

 

前几天在InfoQ看到一篇文章，讲微服务架构如何设计，结合笔者用3年多摸索出来的经验，看了之后很有感受，文章地址如下：

https://www.infoq.com/articles/microservices-design-ideals/?itm_source=infoq&itm_campaign=user_page&itm_medium=link

以前写过一篇文章，关于SOLID原则《架构收藏必备：架构设计的六大原则》，里面讲的就是面向对象设计的时候，如果做到6个原则，但是在工作中发现这种原则面对微服务设计的时候，出现了局限性。

现在的互联网发展太快，各类工具，框架，运用平台都围绕着微服务去建立一个极其丰富的技术体系，对于很多老一辈的人来说，在面向业务责任划分，技术责任划分的时候会有一定经验，但是如果是一个新手去做，此时面对这些服务边界的时候会存在很多疑惑，无法自行进行服务边界的划分，或者无法判断自己划分的服务边界是否是可用的，有没有存在什么藕断丝连的问题，而这些东西，技术上的能力并不能帮我们去很好解决这个问题，IDEALS原则笔者认为，这个核心思想可以帮助我们架构师或者开发人员，更好去理解划分基于微服务的解决方案。

 

IDEALS原则

在IDEALS原则中，作者提出了6个原则，目前这些原则虽然笔者无法保证可以适用于所有的微服务体系的东西，但是却是关键点与成功点。

1、Interface Segregation（接口分离）

2、Deployability（可部署性）

3、EventDriven（事件驱动）

4、Availability Over Consistency（可用性高于一致性）

5、Loose Coupling（松耦合）

6、Single Responsibility（单一责任）

Interface Segregation（接口分离）

最初进行接口设计的时候想着复用，随着项目的推进，发现这个接口越来越臃肿，这里的臃肿不单单是代码量上的增加，更多的是一个接口出现了很多的调用方，后台、小程序、苹果端、安卓端、第三方等，这就导致了同一个服务逻辑里面需要对接很多客户端，后期在进行代码修改的时候经常是牵一发而动全身，所有的客户端不可用的情况会越来越常见，这就是为什么我们要将接口进行隔离。

 

接口隔离有个最重要的目的，就是让不同类型的客