凡客网站规划与建设ppt,建筑方案设计包括什么,网站标题logo怎么做的,贪玩战online你有没有听过这句名言#xff1a;“计算机科学领域只有两个难题#xff0c;缓存失效和命名”#xff1f;据说这句话是Phil Karlton在1996年或1997年左右说的。围绕这句格言确实出现了很多带有喜剧色彩的说法#xff0c;它们也提到了其他的一些问题#xff0c;但最近我对AP…你有没有听过这句名言“计算机科学领域只有两个难题缓存失效和命名”据说这句话是Phil Karlton在1996年或1997年左右说的。围绕这句格言确实出现了很多带有喜剧色彩的说法它们也提到了其他的一些问题但最近我对API世界的观察似乎证明了“命名”确实是个大难题人们对“API”和“微服务”这两个术语存在混淆有些人似乎已经把它们混为一谈了。
计算世界在不断发生变化。开发人员使用各种概念和技术并以不同的方式将它们连接在一起。因此我们使用不一致的术语用多个术语来描述大致相同的概念或者用同一个术语表示不同的事物这些情况并不罕见。
关于API和微服务是的它们是相关的概念它们之间存在相互作用但它们并不是同一种东西。所以我想直截了当地说出我的看法
什么是API
API是应用程序编程接口Application Programming Interface的缩写。维基百科指出“总的来说它是各种组件之间的一组明确定义的通信方法”。它可以是软件框架或库的接口也可以是操作系统为原生系统软件如POSIX开发人员公开的底层接口。
这也是API能够如此令人感到兴奋的一个方面因为各种开发人员可以利用其他人构建和公开的基础设施来增强其应用程序的附加功能。现如今当人们谈论API时他们通常指的是通过HTTP端点公开的远程接口。为了区分这些远程API和上面提到的本地系统API我将用术语“Web API”指代远程API。虽然有些人将这个术语用来指代浏览器的本地API——有点令人困惑对吧
我们通过底层设计范式如查询、RPC或RESTful或协议如SOAP、gRPC或GraphQL进一步对远程API或Web API进行分类。除此之外我们还通过目标受众来区分API将它们分为公共、合作伙伴或私有/内部API。
API的两面性
严格来说API仅用来描述接口也就是客户端和服务器、API消费者和API提供者之间用于交换信息的语言。对于API消费者来说API只不过是对接口和端点URL或URL集的描述。URL是Web的基本构建块之一客户端可以在不知道服务器性质或位置的情况下访问信息或服务。只要客户能够收到响应它根本不管URL是指向隐藏在某个地下室的Raspberry Pi还是位于某个大陆数据中心的全球交付网络。这也是API能够如此令人感到兴奋的一个方面因为各种开发人员可以利用其他人构建和公开的基础设施来增强其应用程序的附加功能。
但是API提供者不仅要设计、实现和文档化API还要考虑它背后的基础设施。在云计算时代可能不需要购买硬件和租用数据中心。相反API提供者可以选择各种“XX即服务”产品——从虚拟机或容器的托管集群到完全无服务器的代码托管环境。无论选择了什么样的基础设施他们都需要部署API。
我这里说的部署API是指部署暴露API所必需的代码和基础设施。从提供者的角度来看API并不是一个神奇的大门而是需要在某个地方运行的有形资产。而且随着公司转向微服务架构这种资产就会变成微服务或一组微服务。
什么是微服务
微服务是系统或应用程序中的自包含独立组件。每个微服务都应该有明确的作用域和责任理想情况下一个微服务只做一件事。它应该是无状态的或有状态的如果它是有状态的它应该带有自己的持久层即数据库不与其他服务共享。软件开发团队基于微服务架构以更分散的方式开发可重用的独立组件。他们可以为每个微服务使用自定义框架、依赖关系集甚至是完全不同的编程语言。微服务也有助于实现可扩展性因为它们本质上是分布式的并且每个微服务都可以独立增长或复制。
容器和微服务
容器是在操作系统中建立隔离上下文的一种方法。实际上这意味着它们中的每一个都有一个单独的包含了一组已安装的软件和相关配置的虚拟文件系统。由于它们是相互隔离的因此任何容器都不能直接访问或影响其他容器或底层宿主操作系统。
创建容器的能力已经成为Linux操作系统的一部分这种能力已经存在了很长一段时间但直到2013年Docker的推出容器才成为一种流行的技术。
当我们在谈论定义时需要注意的是微服务和容器其实是不一样的东西但这两个概念经常被放在一起谈论就像API和微服务一样。如果没有容器要么把服务器配置成可以运行多个微服务让这些微服务不可避免地相互产生负面干扰要么每个微服务都需要一个单独的服务器或自己的虚拟机导致不必要的开销。因此微服务通常被部署在一组由容器集群软件如Kubernetes管理的一组容器中。可以肯定地说容器和微服务的崛起其实是相互影响、相互促进的结果。
微服务之间的通信
基于微服务架构构建的应用程序或API不仅要把自己完全暴露出来还需要在内部组件微服务之间建立连接。由于每个微服务都可以使用不同的编程语言实现我们需要依赖标准协议如HTTP来建立微服务之间的连接。这个时候我们就回到了API上。
最基本的形式是每个微服务都公开一个API让其他服务可以向这个API发出请求并获取数据。也可以使用其他不同的方法比如消息队列。微服务API是私有API仅限用在单个应用程序中。它通常不提供公共URL而是使用组织内部专用网络的私有IP或主机名甚至是单个服务器集群内的IP或主机名。不过这些API可以遵循类似公共API那样的设计范式或协议。而且尽管它们的消费者数量有限也应该遵循开发者体验的基本规则。也就是说它们应该拥有相关的、一致的、可演化的API设计和文档让其他团队甚至是你自己知道如何使用这些微服务。因此你可以而且应该使用类似的工具来创建你的微服务API。
当然与更面向外部的API相比在设计微服务API时有不同的侧重点。微服务和API是不同的东西就像微服务和容器也不是同一种东西一样。不过这两个概念以两种不同的方式协同工作首先微服务可以作为部署内部、合作伙伴或公共API后端的一种方法。其次微服务通常依赖API作为与语言无关的通信手段以便在内部网络中相互通信。开发团队可以使用相似的方法和工具来创建公开API和微服务API。
英文原文https://blog.stoplight.io/stop-calling-your-apis-microservices-e165a80eba9d
