Laravel 如何设计微服务架构，及如何进行微服务间沟通？

微服务的话，lumen 感觉更适合. 我们的微服务全是对外开放的, 然后将API认证跟服务间的请求封装到Packagist,每个服务都composer这个包就好

@OneStep 谢谢回复
我司目前有 2 个专案，一个是旧的 Laravel 单体架构，我打算先维持 Laravel 的架构，后续慢慢拆解成 Lumen 微服务；一个正在开发，也是使用 Lumen
有几个问题请教您：

1. API 认证跟服务间的请求封装到 Packagist 这段可以说明详细点吗，这个包里做了什么，每个服务 require 包之后又要做什么？
2. 微服务全部对外开放的话，不会造成用户端的效能下降吗？且这样如何做 Load Balance 呢？
3. 请问您会如何设计服务间的沟通，如我在文中所述的情景，您会如何在 Lumen 中处理？

packagist 里面封装了各个服务间公用的配置, 还有token验证(其实是由USER的服务提供), 还有各个服务间的通信. require 之后只需要调用就行, 比如服务间的通信 使用

// 获取当前登录用户的ID
app('user')->get('id');
// 向order服务的url发送post请求
app('order')->post('url', data);

每个服务只提供接口, 前端 APP之类的完成业务逻辑,按需调用各个服务
各个服务单独部署的,所以load balance 也没问题的

packagist 里面封装了各个服务间公用的配置, 还有token验证(其实是由USER的服务提供), 还有各个服务间的通信. require 之后只需要调用就行

这个作法真棒，谢谢分享

针对 每个服务只提供接口, 前端 APP之类的完成业务逻辑,按需调用各个服务 想再请教您
我目前想到这样做会有以下几种状况，不知道您会怎么解决

1. 订单成立后因网路问题造成 APP 端没有调用 库存 API
2. 暴露库存 API，会有安全性问题
3. APP 端需呼叫大量 API，降低使用者体验

创业阶段的东西不建议用微服务，创业阶段讲求的是开发效率，而不是架构能撑多少用户。微服务不光会降低开发效率，而且出现问题排查起来也会变得及其麻烦。另外如果服务拆分不合理，微服务将会变成一个技术债务。

再来说说微服务之间的通信，既然已经解耦，那么最好的通信方式就是消息队列。

@TimJuly 谢谢建议
我们目前的状况是已经创业 1 年多，之前也是讲求开发效率而采用单体架构
但因后来 pivot 为工具型平台，我们必须快速调整功能，且不希望功能间互相影响
在这样的考量下我才决定把公司的架构慢慢转向微服务
目前规划的作法是慢慢剥离主架构，所有的新功能都必须采用新架构，借以降低初期的阵痛期
待之后公司发展较稳健，再 Hire 专业的架构师来协助重新调整

@leochien 安全性的话,目前主要靠基于 OAuth 2.0 颁发的token来验证各个接口的访问权限,应该问题不大
前段构成业务逻辑,的确会造成前段请求各个服务的请求比较多,不过感觉影响不大,我们前段都是异步请求的

还有一个是订单创建成功,但是因为网络原因造成前段没有请求库存API, 这个估计就得看没有请求API的原因了,我感觉有2种:

• 已经请求库存API, 但是因为网络问题请求失败 ,这种情况,我们前段一般会根据请求的失败原因(token过期我们一般抛 401, 参数错误 422, 没权限 403 之类的)重构请求, 比如token 过期, API返回:

  {
  success: false,
  data: [],
  errors: {
  code: 'UNAUTHORIZED',
   message: '未授权的请求'
  }
  }

  // 然后前段判断网络状态, 如果401 会调用刷新token的接口更新token,然后重新请求

  post(url, data, res) {
  url: url,
  method: 'POST',
  header: token,
  success: response => {
  if (!response.data.success && statusCode === 401) {
       this.reToken().then(res => {
           post(url, data, res => {
                res(response)
           })
      })
  }
  }
  }

• 还有一种就是没有发送请求了, 这个一般都是业务逻辑的问题了

@OneStep 謝謝回覆，確實使用 Token 能確保不會有權限問題
在服務之前通常會有 LoadBalancer，請問您會選擇每個服務都有各自的 LoadBalancer 嗎？
另外想請教您的 Service Discovery 是如何設計的呢？

@OneStep 可否分享一下你们是怎么用 lumen 来构建微服务的？Thanks~

@leochien 每个服务都可以 LoadBalancer , 不过一般按需来用, 毕竟每个服务的使用频率不一样
Service Discovery 现在尝试使用docker来实现

@LDL1023 如果是构建微服务, 其实跟框架就没多大关系了, 如果你喜欢java, 你也可以用java来开发

@OneStep 自己實現 Service Descovery 不會有點難以維護嗎？我們當初是評估各種微服務解決方案後，選擇最完整的 Kubernetes，既可繼續使用 Docker，又可享受 K8S 的各種好處
再請教您，請問您傾向如何設計微服務間溝通？是讓各微服務互相溝通，還是使用 Message Queue 這類的機制呢？又是如何實作該機制？

恩, 刚去了解了下Kubernetes, 谢谢哦~
服务间的沟通, 基于redis 的Message Queue, 和直接请求都有用, 基于业务场景,请求分为同步响应和异步响应, 异步响应的都是使用的 Message Queue, 同步响应直接就返回响应的数据了,就不做阐述了. 提交异步请求, 需要带一个异步接收地址的参数, 被请求方在队列里处理完成后,通知异步接收地址,然后根据响应内容完成响应的逻辑

@OneStep 我比较喜欢 php，但是现在网上的方案基本都是 java。想知道一下 lumen 是怎么做的

@OneStep 那若是異步請求需要同時呼叫多個服務，各請求又沒有相依關係的話，在這種使用接收地址的方法中，是不是相對會耗用較多請求資源，比起廣播來說
@LDL1023 我認為微服務的重點在於架構設計是否合理，彼此的溝通方式是否定義明確，若設計良好的微服務應可由數種不同語言來實現各服務

@leochien 我感觉广播的话也有局限性,因为是单向的数据流,跟踪处理结果会比较麻烦,例如 网络异常, 参数错误....等导致请求失败
我们同步请求后,被请求方会立即返回数据或者请求结果(处理成功或者失败), 异步的场景主要是被请求方处理周期比较长,或者频率很高,需要使用队列等情况, 但是处理成功后也会返回处理结果或者数据, 这样请求方可以根据处理结果或者数据继续处理自己的逻辑

@LDL1023 微服务只是种架构思想,把一个服务拆分为很多小的服务(例如商城拆分为: 用户,订单,商品,支付,物流等), 各个服务间相对独立,这样维护扩展起来比较方便, 比如 用户 模块, 你用lumen 需要完成 用户的增删改查等功能, 然后提供统一标准的API .
这样你应该比较好理解

想请教一下API Gateway是什么？

@PENGPN 我也是很久很久之前听到这个名词，没人给我解释，我片面理解

上面讲的微服务架构，这些服务对外开放的接口，我理解为网关。

大佬，您的实践怎么样？