合作机构:阿里云 / 腾讯云 / 亚马逊云 / DreamHost / NameSilo / INWX / GODADDY / 百度统计
在这一系列文章中,我们将从架构、设计等不同方面来探讨,在云的可移植性方面,具体都需要考虑哪些细节问题,如何最大限度避免云时代的技术锁定,充分发挥云的灵活性优势。
延伸阅读,了解 Akamai cloud-computing
出海云服务,选择Akamai cloud-computing!
下文将简要探讨云原生和容器技术。欢迎点击这里回顾上篇内容,了解云原生和容器技术在云可移植性方面的注意事项。
微服务应该是可扩展的,并且是专注于单一职能的,由每个自包含的模块化单元负责处理一个更大规模系统中的一个特定功能,而大型应用程序往往就可以由这种模块化的组件或服务(如容器或无服务器计算)构建而成。
我们可以将微服务看作由不同部门、预算和要求组成的业务。每年,这些要求都会根据公司需求的变化而变。随着时间推移,我们的应用程序也会面对不断变化的要求,其中的某些方面可能会产生更多需求,有些方面则需要我们投入更多关注。此外,应用程序中的不同方面可能还需要进行不同程度的扩展或缩放。微服务可以帮助我们在不影响其他方面的情况下,以独立的方式对应用程序中的某些方面进行缩放或扩展。
相信大家都还记得编程领域所谓的“单一职责原则”(Single responsibility principle)。微服务在这方面也是一样的。微服务应该只负责做一件事,并且做好这件事。当然,通过使用微服务,我们还能在弹性和容错能力方面获得一些固有的好处。微服务架构旨在通过将故障约束到单个服务来防止出现影响整个系统的故障。如果出现特定故障,我们将知道故障位于哪里,并能在不影响其他东西的情况下解决这种故障。
另外还要注意可发现(Discoverable)问题。通过使用诸如HashiCorp的Consul这种服务网络解决方案,我们将能知道新服务何时上线,并能使用一个集中的系统充当服务目录,从而定义这些服务的用途以及服务之间的通信方式。
保持微服务规模小巧、专注于负责单一业务能力,这一点至关重要。这样我们才能轻松添加额外的功能并避免蔓延。然而,每个微服务的理想规模是多少,这并没有什么明确标准,这需要我们根据具体应用及实际需求来决定。
我们还需要针对失败进行相关设计。虽然多个服务和微服务运行过程中,按照设计本身就具备与生俱来的容错能力,但额外的设计可以增加额外的弹性,例如重试机制、断路器以及隔板。想象一下船舶为什么会安装隔板。这些隔板可以保证船舶的结构完整性,而如果船舱漏水,隔板关闭,也可以保证船不会沉没。很多基于事件驱动的架构使用了一种所谓的死信队列(Dead letter queue),如果某条消息无法传递,就会被放入一个特殊的队列,接下来就可以检查该队列中的消息来确定失败原因。
微服务应该围绕领域驱动(Domain-driven)的设计原则来设计,这意味着要基于业务能力对服务建模,并使用通用语言来保障服务符合业务需求。领域驱动的设计侧重于围绕对业务的深入理解来打造软件系统,其原则有助于指导设计过程,确保软件与领域保持一致且能为业务提供价值。这些原则共同促进了对业务领域的深入理解,有助于确保开发工作能与业务需求和不断变化的要求紧密契合。
采取以API为先的方法进行设计并实现API网关,借此即可提供中央连接点,从而促进微服务和第三方子系统之间的通信。API网关负责处理大部分路由工作,以及身份验证、认证、速率限制等工作。API的设计模式对于微服务的模块化和可复用能力至关重要。
此外对于微服务,还有下列这些最佳实践:
这篇文章的内容感觉还行吧?有没有想要立即在 Linode 平台上亲自尝试一下?别忘了,现在注册可以免费获得价值 100 美元的使用额度,快点自己动手体验本文介绍的功能和服务吧↓↓↓
出海云服务,Akamai是您的不二之选!
欢迎关注Akamai ,第一时间了解高可用的MySQL/MariaDB参考架构,以及丰富的应用程序示例
TOP