什么是松散耦合的架构？

      散耦合的架构是一种软件应用程序开发模式，其中多个组件相互连接，但并不严重依赖对方。这些组件共同创建了一个总的网络或系统，尽管每个服务都是为执行单一任务而创建的独立实体。松散耦合架构的主要目的是创建一个不会因为单个组件的失败而失败的系统。面向服务的架构（SOA）通常由松散耦合的架构组成。

      松散耦合架构的例子
考虑一个实例，你在一个程序中创建了两个类，A和B。当A类的方法调用B类的方法或使用B类中定义的变量实例时，两个类是紧密耦合的。然而，当A类依赖于B类的接口而不是B类中定义的方法时，两个类是松散耦合的。

       以上是一个使用松散耦合系统的订餐应用程序的例子。该应用程序包含不同的服务，如订单服务、餐厅服务、送货服务和客户服务。当客户订购食品时，订单服务负责处理。餐厅服务接收这些数据并准备好食物，而送餐服务则处理送餐部分。客户服务在需要时为客户提供协助。在这种情况下，每个单独的服务并不严重依赖其他任何服务。所有服务都通过API进行通信，以便发送和接收所需的信息。因此，当一个服务崩溃时，它可以立即被替换，而不会干扰到应用程序的其他组件。同样，订单服务可以在高峰期或季节中自动扩展。

      松散耦合的架构与紧密耦合的架构
松散耦合与紧密耦合的架构是一个需要思考的重要问题。在软件开发领域，耦合是指一个对象对另一个对象的依赖性。一个对象对另一个对象的了解程度或一个对象对另一个对象的依赖程度决定了系统是松散耦合还是紧密耦合。当依赖程度很低时，我们说它是松散耦合的。基本上，这意味着一个对象知道其他对象通过API暴露出来的东西。同样地，当一个系统的变化不会迫使另一个系统发生变化时，两个系统就是松散耦合的。

松散耦合系统中的每个服务都被设计成具有单一的目的或责任，可以独立部署、管理、扩展和移除。每个服务都包含一个用于通信的接口（REST API）。由于每个服务可以使用不同的编程语言、平台、技术和框架，所以很容易对单个服务进行修改、执行测试、扩展服务和删除服务而不影响系统。松散耦合的架构容纳了广泛的API和与接口解耦的可互操作的资源模式。

      另一方面，紧耦合架构中的对象严重依赖于系统的其他组件。每个对象必须与其他对象或组件协作和协调，以完成一个功能。在这种情况下，一个类的逻辑被另一个类所调用。这意味着一个对象或类需要另一个对象或类来完成一项任务。因此，每个类都承担着多种责任，对一个类的改变也迫使一个或多个其他类发生改变。

微服务在松散耦合的架构中的重要性
       微服务是一种架构设计，有利于将应用程序开发成小型独立的服务，这些服务运行自己的流程，并使用轻量级协议和消息系统进行通信，使其与平台无关，与语言无关。每个服务都是独立的、可测试的、高度可维护的、可独立部署的，并且实现了一种业务能力。最重要的是，每个服务都由一个小团队来维护、部署、创建和拥有。微服务是面向服务的架构的一个明显的变体，它利用了松散耦合的架构方法。事实上，松散耦合是微服务架构的关键组成部分。

微服务架构对于创建一个松散耦合的系统是非常重要的，因为耦合在软件系统设计中是不可避免的。例如，在一个电子商务门户中，订单服务应该使用API与客户服务或交付服务进行通信。也就是说，微服务允许你尽可能地保持这种耦合性。

微服务由一组协作的服务组成，它们使用不同的耦合方法一起工作。

运行时耦合。一个服务的可用性影响另一个服务的可用性的程度。
设计时耦合。一个服务的变化会引发另一个服务的变化的程度。
基础设施耦合。一个服务的资源消耗影响另一个服务的资源消耗的程度。
每种耦合方法都带来了自己的挑战。例如，运行时耦合会在变化发生时降低可用性。因此，在微服务架构中，你会遇到一个很长的调用队列。

当你实施设计时耦合时，API的一个小变化需要改变所有与该API交互的服务。因此，所有与这些服务有关的团队都必须合作并讨论这个变化。因此，保持设计时耦合尽可能的松散是很重要的，特别是当不同的协作团队参与进来的时候。

微服务使设计时耦合模型很容易实现松散耦合，同时使你能够使用精益开发和DevOps CI/CD最佳实践有效地处理耦合挑战。

哪些AWS服务可用于松散耦合的架构？
亚马逊简单排队服务（SQS）和简单通知服务（SNS）是强大的机制，可以帮助你建立高度可扩展和松散耦合的架构，在平台、网络和操作层面上进行耦合：
亚马逊简单排队服务（SQS）。当客户下订单时，接收该订单的应用程序将其作为消息发送到SQS。该消息被排队，并由AWS Lambda等函数消费。一旦消息被处理，它就会被自动删除。
亚马逊简单通知服务（SNS）。以 "发布-订阅 "的模式工作，其中应用程序将订单消息发送到SNS主题，然后在不同的端点上复制，以便并行运行进程。
  AWS Lambda。无服务器计算引擎。
  AWS Fargate。用于无服务器计算的容器即服务。
  AWS AutoScaling。自动缩放服务。
  亚马逊S3。存储服务。
  亚马逊API网关。API管理服务。
  AWS CloudWatch。用于管理SQS中的消息。

松散耦合的架构场景
       与紧耦合架构不同的是，松耦合架构在单个节点上大量运行较小的作业，并在节点内进行并行化，而紧耦合架构运行的是成千上万个相互依赖的并行进程或内核，以进行计算。由于进程之间的依赖性不高，失去一个节点并不影响整体功能。作业要么稍后处理，要么被删除。

在选择松散耦合的架构时，必须考虑以下几个方面:

计算--底层的EC2实例类型应该根据应用程序的内存与计算比率来确定。
网络--在松散耦合的情况下，带宽和延迟问题不是一个问题，因为并行运行的进程不需要太多的互动。
存储--每个松散耦合的应用程序都有不同的存储要求。因此，要考虑数据集大小和数据传输要求。
部署--鉴于松散耦合的应用程序在安装在不同可用区的核心上运行，它们可以使用AWS Parallel Cluster或AWS Batch进行有效部署。

具有松散耦合架构的AWS无服务器方案
       无服务器计算是一种云原生软件开发方法，可以帮助企业轻松、无缝地构建和运行应用程序，而没有配置和管理服务器的负担。服务器仍然被使用，但由云计算供应商管理。这里的问题是，收费不是基于服务器的数量或带宽，而是基于使用率。它使企业能够以现收现付的方式购买后端服务器，只为使用的服务付费。

无服务器计算有两种模式。

1. 功能即服务。一种允许你根据事件运行代码的服务，没有复杂的基础设施管理。应用程序以无状态模式运行，其中服务器和客户端是松散耦合的，因此是独立、灵活、可扩展和容错的。

关于计算引擎，AWS Lambda是AWS的一个流行的无服务器FaaS工具。对于基于容器的工作负载，可以使用AWS Fargate。对于事件触发，我们推荐使用Amazon SQS、AWS SNS和Eventbridge。

2. 后台即服务。运行服务器端逻辑的任务被外包给一个云供应商。AWS BaaS工具包括用于记录的Amazon Elasticsearch Service、用于分析的AWS Kinesis和用于IAM的AWS Cognito。

有三种类型的无服务器调用方法:

同步调用--当客户端请求需要立即响应时使用。
异步调用--当你不希望客户端等待响应，而是在流程完成后通过通知提醒客户端时使用。
流式调用--用于以相同的速度进行上游、处理和下游的数据。
谈到无服务器计算，带有异步方法的松耦合架构是一个不错的选择。也就是说，不要忘了确保它是故障快速的，并能正确地扇出。

结论
       软件技术迅速变化，迫使组织不断适应新的技术和趋势。当涉及到松散耦合与紧密耦合的架构时，信息流和服务之间的协调在紧密耦合的架构中会更好。然而，在对你的应用程序进行修改时，它们会限制你的灵活性。松散耦合的架构是当下的需要。它不仅允许你即时交换或扩展组件，而且还能帮助你在不影响现有系统的可用性和性能的情况下增加新的功能。通过微服务、精益开发和DevOps实践，松散耦合的架构让你在竞争中保持优势，甚至领先。

---

今天先到这儿，希望对云原生，技术领导力， 企业管理，系统架构设计与评估，团队管理, 项目管理, 产品管管，团队建设 有参考作用 , 您可能感兴趣的文章:
领导人怎样带领好团队
构建创业公司突击小团队
国际化环境下系统架构演化
微服务架构设计
视频直播平台的系统架构演化
微服务与Docker介绍
Docker与CI持续集成/CD
互联网电商购物车架构演变案例
互联网业务场景下消息队列架构
互联网高效研发团队管理演进之一
消息系统架构设计演进
互联网电商搜索架构演化之一
企业信息化与软件工程的迷思
企业项目化管理介绍
软件项目成功之要素
人际沟通风格介绍一
精益IT组织与分享式领导
学习型组织与企业
企业创新文化与等级观念
组织目标与个人目标
初创公司人才招聘与管理
人才公司环境与企业文化
企业文化、团队文化与知识共享
高效能的团队建设
项目管理沟通计划
构建高效的研发与自动化运维
某大型电商云平台实践
互联网数据库架构设计思路
IT基础架构规划方案一(网络系统规划)
餐饮行业解决方案之客户分析流程
餐饮行业解决方案之采购战略制定与实施流程
餐饮行业解决方案之业务设计流程
供应链需求调研CheckList
企业应用之性能实时度量系统演变

如有想了解更多软件设计与架构, 系统IT,企业信息化, 团队管理 资讯，请关注我的微信订阅号：

作者：Petter Liu
出处：http://www.cnblogs.com/wintersun/
本文版权归作者和博客园共有，欢迎转载，但未经作者同意必须保留此段声明，且在文章页面明显位置给出原文连接，否则保留追究法律责任的权利。 该文章也同时发布在我的独立博客中-Petter Liu Blog。