江苏龙网

  1. 首页 > 人文 > >

#客户端#腾讯T4-1手写44个微服务架构设计模式，全部学会真的太厉害了( 二 )


■由第三方开发人员编写的应用程序 。
Web应用程序在防火墙内部运行 ， 因此它们通过高带宽、低延迟的局域网访问服务 。 其他客户端在防火墙之外运行 ， 因此它们通过较低带宽、较高延迟的互联网或移动网络访问服务 。
API的一种设计思路是让客户端直接调用服务 。 从表面上看 ， 这听起来非常简单 ， 毕竟 ， 这就是客户端调用单体应用程序的API的方式 。 但由于存在以下弊端 ， 这种方法很少用于微服务架构：
■细粒度服务API要求客户端发出多个请求以检索所需的数据 ， 这样做效率低 ， 并且可能导致糟糕的用户体验 。
■由于客户端了解每项服务以及服务的API从而导致封装不足(紧耦合)因此今后很难更改服务的架构和API 。
”服务可能使用对客户端而言不便或不能使用的进程间通信机制 ， 尤其是防火墙外的客户端 。
要了解有关这些弊端的更多信息 ， 让我们来看看FTGO移动应用程序如何从服务中检索数据 。
8.1.1 FTGO 移动客户端API的设计难题
消费者使用FTGO移动客户端来下订单和管理他们的订单 。 想象一下 ， 你正在开发移动客户端的View Order视图 ， 该视图显示订单 。 如第7章所述 ， 此视图显示的信息包括基本订单信息 ， 如订单状态、付款状态、餐馆视角下的订单状态 ， 以及送餐状态(包括其位置和运输过程中的预计送餐时间) 。
FTGO应用程序的单体版本具有返回订单详细信息的API接口 。 移动客户端通过发出单一请求来检索所需的信息 。 相比之下 ， 在FTGO应用程序的微服务版本中 ， 如前所述 ， 订单详细信息分散在多个服务中 ， 包括以下内容:
■Order Service: 基本订单信息 ， 包括详细信息和状态 。
■Kitchen Service: 餐馆视角下的订单状态以及送餐员可以取餐的预计时间 。
■Delivery Service: 订单的送餐状态 ， 预计送餐时间和当前位置 。
如果移动客户端直接调用服务 ， 则必须如图8-2所示 ， 进行多次调用以检索此数据 。
在此设计中 ， 移动应用程序扮演着API组合器的角色 。 它调用多个服务并组合结果 。 尽管这种方法看似合理 ， 但它有几个严重的问题 。
...........................
8.1.2其他类型客户端API的设计难题
8.2 API Gateway模式
8.2.1什么是 API Gateway模式
8.2.2 API Gateway模式的好处和弊端
8.2.3以Netlix为例的API Gateway
8.2.4 API Gateway的设计难题
8.3实现一个 API Gateway
8.3.1使用现成的 API Gateway产品或服务
8.3.2开发自己的API Gateway
8.3.3使用GraphQL实现API Gateway
第12章部署微服务应用12.1部署模式: 编程语言特定的发布包格式
12.1.1使用编程语言特定的发布包格式进行部署的好处
12.1.2使用编程语 言特定的发布包格式进行部署的弊端
12.2部署模式: 将服务部署为虚拟机
12.2.1将服务部署为虚拟机的好处
12.2.2将服务部署为虚拟机的弊端
12.3部署模式: 将服务部署为容器
12.3.1使用 Docker部署服务
12.3.2将服务部署为容器的好处
12.3.3将服务部署为容器的弊端
12.4使用Kubernetes部署FTGO应用程序
12.4.1什么是Kubernetes
12.4.2在 Kubernetes.上部署Restaurant Service
12.4.3部署 API Gateway
12.4.4零停机部署
12.4.5使用服务网格分隔部署与发布流程
12.5部署模式: Serverless部署
12.5.1使用 AWS Lambda进行Serverless部署
12.5.2开发Lambda函数
12.5.3调用Lambda函数
12.5.4使用Lambda函数的好处
12.5.5使用Lambda函数的弊端
【#客户端#腾讯T4-1手写44个微服务架构设计模式，全部学会真的太厉害了】12.6使用AWS Lambda和AWS Gateway部署RESTful服务


推荐阅读


上一篇：黑客@2名顶级黑客轻松“入侵”支付宝，转账完成后1秒，屏幕弹出一行字

下一篇：『』假如一条河里的鱼，5年没人吃，会不会鱼满为患？