什么是微服务，微服务应该怎样划分服务，微服务之间存在关联怎么办？

什么是微服务？

 

官方给的原文是：

Microservice architectures are the ‘new normal’. Building small, self-contained, ready to run applications can bring great flexibility and added resilience to your code
微服务体系结构是“新常态’。 构建小型的、独立的、可以运行的应用程序，可以给您的代码带来很大的灵活性和额外的弹性。

什么是微服务，可能连现在正在做微服务的猿们都说不清楚。官方给出的是很简单的一句话，说明微服务的特性：小型的、独立的、可运行的应用程序，组合成一个大的功能，这样做可以使服务的复用性更高，那直接就可以拿过用，并且每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在出现故障时不会相互影响，难道这就是微服务吗？

微服务的边界如何划分?

 微服务的边界如何划分，这个问题是一个很难的问题，每一个系统都有不同的划分原则，具体根据业务来，但是肯定是按照高内聚，低耦合的原则来划分的。低耦合就是服务与服务之间的关联性要减少，高内聚则是相关联的行为聚合再一起。

那么我们实际应用中按照高内聚，低耦合来划分试一下：

• 比如我有一个基础服务是提供人员信息的服务，这个基础人员中有各个部门的人：技术部、工程部、管理部等，那么人员信息是肯定和部门关联的，那么我们就要把人员和部门放在一起。

• 现在说说工程部：工程部要对公司的设施进行检查和检修，工程部的领导会制定相关的巡检计划（本来应该是管理部的，不想说的太复杂），一个巡检单子，可能有多个员工，到这里是不是好多人都要说了，这简单呀，只需要一个关联表里面存放员工的唯一标识，再加上一些简单的常用字段就行了。是的没错，可是客户偏偏有变态的需求，他要求将员工的姓名，手机号，部门显示在列表里面。如果我们将这些字段存在关联表中，那么我员工的电话号码已经改了，但是你这边还是显示的是以前的电话。我已经从工程部跳到技术部了，你还显示我是工程部的呢，这是不是就很难了，难道我还要把工程部放在基础人员信息中，这显然是不对的

微服务之间存在关联怎么办？

上面只是举一个简单的例子，关联关系还不是很强，实际的项目肯定有比这个更变态的，我在网上查了一下微服务关系如何解决，基本上是三种解决方案

1. 就是开发的时候就直接在内部实现关联查询，在外部还是一样的，每个服务提供相应的服务，只不过我查询人员信息的时候都是通过工程部的服务查询

2. 有关联关系的放在单独的服务中进行查询，提供单独的接口（这个很有意思，每个服务还能提供唯一的功能，还能再进行关联查询，可是我觉得冗余太多，并且我觉得实际项目中可能大部分的业务都有关联）

3. 这个效率是非常低的一种方式，先查询出来巡检单的列表，在循环遍历查找人员信息，填充到巡检单的数据中。

结语

 到这里基本就结束了，到目前为之我还是很迷茫，不知道何为微服务，就像上面的这种情况，是业务划分的不明确，还是项目根本就不适合微服务。

说说我实际的项目的，我在公司就碰到了关联问题，于是这几天，我天天在想标题的三个问题，不明白、不明白、不明白。最客气的是公司的技术团队尽然一致的通过了解决关联关系的第三种方案，这...，我真的无语，我们要做微服务没有错，但是我做微服务是为了什么。

最后微服务只是一门技术，是技术就是为了我们项目服务的，而不是项目服务于技术。这是完完全全的本末倒置。

另：如果有更好的微服务关联解决方案，麻烦大神们@我哟