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

■由第三方开发人员编写的应用程序。
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服务