SOA之微服务在项目中的设计理念

 PS：以下是笔者在两年前看过一些片面文章后，所罗列出的一些浅薄的理论知识，在当初并未在实际项目中有所运用，所以欠缺点还是有很多

后来笔者在一个呼叫中心项目中才浅显的 略微理解了微服务架构体系，以及微服务一些落地。

SOA概念

       面向服务架构，是构造分布式系统的方法论，也提供一些标准和工具。、

 

分布式

       一个服务器能做的事情，可以多个服务器去做，减轻压力。

 

分布式诞生的原因

     系统架构演变过程     

    以早期的电商平台为例，UI层调用服务层(分了N多得模块)，服务层调用DB，这样的系统瓶颈会很多

 

 

 

 

 

随着业务需求的提升，此时的系统架构无法满足需求，于是系统架构进行了升级

出现了分库分表的概念，来解决数据库所带来的瓶颈问题，但是又出现了新的问题

比如用户在下了一个订单之后，要同时收集多个模块里包含的一些信息，那么需要

链接的数据库也将会很多，导致系统性能大降。

 

 

 

系统架构再一次进行调整，UI层会访问企业数据总线，而比如订单、财务等会做成

服务，需要订单信息的就访问订单服务诸如此类，将不再直接操作数据库，而是通过

服务，企业数据总线叫网关，在微服务架构中有体现，数据总线会调用提供的服务，服务发布

的时候需要注册到数据总线

 

 

 

但是更多的时候，系统并不是这么理想化的一步步演变，很多情况是有N多个系统需要互相交互

不管是从系统的稳定性还是各个方面来看，这无疑是很糟糕的情况，但是现有的各种系统又无法

重构且需要满足业务需求，SOA针对于这种情况也提供了一种解决方案，建立一个数据总线，并定义

标准，各个系统之间不再直接交互，而是通过数据总线去完成交互

 

 

 

写好的服务需要注册到数据总线，数据总线不做其他事情只是类似于网关中转一样

可以理解为服务向数据总线注册时就写了一些IP地址端口协议格式等信息，Client

调用的时候就像根据Key去数据总线找(因为在注册的时候，服务肯定要描述你这个服务是要干嘛的)

实际上Client还是直连的服务，不过不再直接去找而是找数据总线要

 

以笔者所经历的呼叫中心的项目为例进行拓展

1.项目整体结构： web端 + 中间件+调用第三方服务端(如企业微信、机器人等等)

前言： web端有很多功能，这里举例  用户点击一个聊天框，输入需要帮助的问题，可以选择人工，也可能是从知识库中获取到的答案。

用户打开聊天窗口，这里是一次请求，可能等待一分钟后或者更长、更短的时间间隔后，才输入相关内容，返回答案或人工回复后，用户可能再次立即输入类容并发送，也有

可能间隔一段时间后再次输入内容发送。从服务器的角度而言，用户打开窗户视为一次请求(与服务器建立连接),返回答案又是一次请求，等待的过程中，服务器如何在间断的

时间内，再次请求。

    众所周知，http请求是无法进行常连接的，所以我们在web端会制定一个心跳检测机制，即每隔60秒请求一次中间件，会带入一些制定的参数，用来识别本次请求是是否是同一对话框的。在中间件我们用tcp协议侦听web发送过来的请求，进行相关参数的判断(检测过来的请求源是否为同一源)，然后进行转发(至企业微信、微信、机器人等)，然后再将返回的参数识别后发送给web端。

   这样做的好处：各位服务器上的服务只需要关心自己的事,web端不再是直连server，要什么找中间件要。充分利用各个服务器的资源，这里的概念就用到了微服务的数据总线的

概念。