2024年10月soa微服务（微服务入门这一篇就够了）
⑴soa微服务（微服务入门这一篇就够了
⑵微服务入门这一篇就够了
⑶刚开始进入软件行业时还是单体应用的时代，前后端分离的概念都还没普及，开发的时候需要花大量的时间在“强大”的JSP上面，那时候SOA已经算是新技术了。现在，微服务已经大行其道，有哪个互联网产品不说自己是微服务架构呢？
⑷但是，对于微服务的理解每个人都不太一样，这篇文章主要是聊一聊我对微服务的理解以及如何搭建经典的微服务架构，目的是梳理一下自己的一些想法，如果存在不同看法的欢迎指正！
⑸首先，什么是微服务呢？
⑹相对的，要理解什么是微服务，那么可以先理解什么是单体应用，在没有提出微服务的概念的“远古”年代，一个软件应用，往往会将应用所有功能都开发和打包在一起，那时候的一个B/S应用架构往往是这样的：
⑺但是，当用户访问量变大导致一台服务器无法支撑时怎么办呢？加服务器加负载均衡，架构就变成这样了：
⑻后面发现把静态文件独立出来，通过CDN等手段进行加速，可以提升应用的整体相应，单体应用的架构就变成：
⑼上面中架构都还是单体应用，只是在部署方面进行了优化，所以避免不了单体应用的根本的缺点：
⑽我认为任何技术的演进都是有迹可循的，任何新技术的出现都是为了解决原有技术无法解决的需求，所以，微服务的出现就是因为原来单体应用架构已经无法满足当前互联网产品的技术需求。
⑾在微服务架构之前还有一个概念：SOA（Service-OrientedArchitecture-面向服务的体系架构。我认为的SOA只是一个架构模型的方法论，并不是一个明确而严谨的架构标准，只是后面很多人将SOA与TheOpenGroup的SOA参考模型等同了，认为严格按照TOG-SOA标准的才算真正的SOA架构。SOA就已经提出的面向服务的架构思想，所以微服务应该算是SOA的一种演进吧。
⑿撇开架构先不说，什么样的服务才算微服务呢？
⒀微服务架构，核心是为了解决应用微服务化之后的服务治理问题。
⒁应用微服务化之后，首先遇到的第一个问题就是服务发现问题，一个微服务如何发现其他微服务呢？最简单的方式就是每个微服务里面配置其他微服务的地址，但是当微服务数量众多的时候，这样做明显不现实。所以需要使用到微服务架构中的一个最重要的组件：服务注册中心，所有服务都注册到服务注册中心，同时也可以从服务注册中心获取当前可用的服务清单：
⒂解决服务发现问题后，接着需要解决微服务分布式部署带来的第二个问题：服务配置管理的问题。当服务数量超过一定程度之后，如果需要在每个服务里面分别维护每一个服务的配置文件，运维人员估计要哭了。那么，就需要用到微服务架构里面第二个重要的组件：配置中心，微服务架构就变成下面这样了：
⒃以上应用内部的服务治理，当客户端或外部应用调用服务的时候怎么处理呢？服务A可能有多个节点，服务A、服务B和服务C的服务地址都不同，服务授权验证在哪里做？这时，就需要使用到服务网关提供统一的服务入口，最终形成典型微服务架构：
⒄上面是一个典型的微服务架构，当然微服务的服务治理还涉及很多内容，比如：
⒅目前国内企业使用的微服务框架主要是SpringCloud和Dubbo（或者DubboX，但是Dubbo那两年的停更严重打击了开发人员对它的信心，SpringCloud已经逐渐成为主流，比较两个框架的优劣势的文章在网上有很多，这里就不重复了，选择什么框架还是按业务需求来吧，业务框架决定技术框架。SpringCloud全家桶提供了各种各样的组件，基本可以覆盖微服务的服务治理的方方面面，以下列出了SpringCloud一些常用组件：
⒆本章节主要介绍如何基于SpringCloud相关组件搭建一个典型的微服务架构。首先，创建一个Maven父项目spring-cloud-examples，用于管理项目依赖包版本。由于SpringCloud组件很多，为保证不同组件之间的兼容性，一般通过spring-cloud-dependencies统一管理SpringCloud组件版本，而非每个组件单独引入。
⒇pom.xml配置如下：
⒈参考上面业务服务A搭建另外一个业务服务B。
⒉目前网上很多说是下一代微服务架构就是ServiceMesh，ServiceMesh主流框架有Linkerd和Istio，其中Istio有大厂加持所以呼声更高。ServiceMesh我接触还不多，但是个人感觉并不一定能称为下一代微服务架构，可能认为是服务治理的另外一种解决方案更合适，是否能够取代当前的微服务架构还需要持续观察。
⒊SOA和微服务架构的区别
⒋SOA与微服务架构，在架构划分、技术平台选择等方面，均存在一定的区别。
⒌SOA强调按水平架构划分为：前、后端、数据库、测试等；
⒍微服务强调按垂直架构划分，按业务能力划分，每个服务完成一种特定的功能，服务即产品。
⒎SOA应用倾向于使用统一的技术平台来解决所有问题；
⒏微服务可以针对不同业务特征选择不同技术平台，去中心统一化，发挥各种技术平台的特长。
⒐系统间边界处理机制不同
⒑SOA架构强调的是异构系统之间的通信和解耦合；（一种粗粒度、松耦合的服务架构；
⒒微服务架构强调的是系统按业务边界做细粒度的拆分和部署。
⒓SOA架构，主要目标是确保应用能够交互操作；
⒔微服务架构，主要目标是实现新功能、并可以快速拓展开发团队。
⒕百度百科-微服务架构
⒖面向过程、面向对象、面向服务、微服务
⒗面向过程：POP（procedureorientedprogramming面向对象：OOP（objectorientedprogramming面向服务：SOA（service-orientedArchitecture
⒘所谓的微服务是SOA架构下的最终产物，该架构的设计目标是为了肢解业务，使得服务能够独立运行。微服务设计原则：、各司其职、服务高可用和可扩展性。
⒙jee和微服务架构区别
⒚二者是本质上的区别。、微服务与SOA之间的另一个不同之处是服务互联和编写服务时所使用的技术。、JEE是一个遵循企业级标准的用于编写SOA架构的技术栈。
⒛SOA和微服务架构的区别
微服务是一个新概念，但这绝不是一个全新架构，更不是一个包治百病的架构。由于有服务二字，很容易让人联想到面向服务架构（SOA，其实微服务架构属于应用技术架构，和以B/S为代表的三层架构相对应，强调将巨石型应用拆分为由微服务组成的应用，在数据上也视情况从集中的存储拆解为更小的存储单元。而SOA属于企业架构的范畴，从企业架构出发把业务分解为不同领域的服务，不同物理系统提供不同服务，注重系统之间通过服务互联互通的规范，对服务如何实现并不关注。因此，面向服务架构的服务应该是一个业务意义的服务，而微服务是系统中的技术服务，更关注服务的实现，虽然提供了业务意义的服务，但是不能混为一谈。微服务使用也不是无限度的，事实上由于数据一致性等问题的限制，不能无限度拆分微服务，可以把微服务分为系统对外提供的远程服务、系统内部的远程服务和系统内部的本地服务，显式声明、明确职责。事实上，在企业架构上使用SOA支撑业务，而在应用技术架构上使用微服务架构，是一个合适的选择。
面向服务的架构（SOA是一个组件模型，它将应用程序的不同功能单元（称为服务通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。面向服务架构，它可以根据需求通过网络对松散耦合的粗粒度应用组件进行分布式部署、组合和使用。服务层是SOA的基础，可以直接被应用调用，从而有效控制系统中与软件代理交互的人为依赖性。SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型。SOA可以看作是B/S模型、XML（标准通用标记语言的子集/WebService技术之后的自然延伸。SOA将能够帮助软件工程师们站在一个新的高度理解企业级架构中的各种组件的开发、部署形式，它将帮助企业系统架构者以更迅速、更可靠、更具重用性架构整个业务系统。较之以往，以SOA架构的系统能够更加从容地面对业务的急剧变化。
微服务架构是一种方法，其中单个应用程序由许多松散耦合且可独立部署的较小服务组成。微服务（或微服务架构是一种云原生架构方法，其中单个应用程序由许多松散耦合且可独立部署的较小组件或服务组成。这些服务通常虽然关于微服务的大部分讨论都围绕架构定义和特征展开，但它们的价值可以通过相当简单的业务和组织优势来更普遍地理解：微服务也可以通过它们不是什么来理解。与微服务架构最常进行的两个比较是单体架构和面向服务的架构(SOA)。微服务和单体架构之间的区别在于，微服务由许多较小的、松散耦合的服务组成一个应用程序，而不是大型、紧密耦合的应用程序的单体方法微服务和SOA之间的区别可能不太清楚。虽然可以在微服务和SOA之间进行技术对比，尤其是围绕企业服务总线(ESB)的角色，但更容易将差异视为范围之一。SOA是企业范围内的一项努力，旨在标准化组织中所有Web服务相互通信和集成的方式，而微服务架构是特定于应用程序的。微服务可能至少与开发人员一样受高管和项目负责人的欢迎。这是微服务更不寻常的特征之一，因为架构热情通常是为软件开发团队保留的。原因是微服务更好地反映了许多业务领导者希望构建和运行他们的团队和开发流程的方式。换句话说，微服务是一种架构模型，可以更好地促进所需的操作模型。在IBM最近对,多名开发人员和IT主管进行的一项调查中，%的微服务用户同意微服务的采用是值得的。也许微服务最重要的一个特点是，由于服务更小并且可以独立部署，它不再需要国会的法案来更改一行代码或在应用程序中添加新功能。微服务向组织承诺提供一种解毒剂，以解决与需要大量时间的小改动相关的内心挫败感。它不需要博士学位。在计算机科学中看到或理解一种更好地促进速度和敏捷性的方法的价值。但速度并不是以这种方式设计服务的唯一价值。一种常见的新兴组织模型是围绕业务问题、服务或产品将跨职能团队聚集在一起。微服务模型完全符合这一趋势，因为它使组织能够围绕一个服务或一组服务创建小型、跨职能的团队，并让他们以敏捷的方式运行。微服务的松散耦合还为应用程序建立了一定程度的故障隔离和更好的弹性。服务的小规模，加上清晰的边界和沟通模式，使新团队成员更容易理解代码库并快速为其做出贡献——在速度和员工士气方面都有明显的好处。在传统的n层架构模式中，应用程序通常共享一个公共堆栈，其中一个大型关系数据库支持整个应用程序。这种方法有几个明显的缺点——其中最重要的是应用程序的每个组件都必须共享一个公共堆栈、数据模型和数据库，即使对于某些元素的工作有一个清晰、更好的工具。它造成了糟糕的架构，并且对于那些不断意识到构建这些组件的更好、更有效的方法是可用的开发人员来说是令人沮丧的。相比之下，在微服务模型中，组件是独立部署的，并通过REST、事件流和消息代理的某种组合进行通信——因此每个单独服务的堆栈都可以针对该服务进行优化。技术一直在变化，由多个较小的服务组成的应用程序更容易和更便宜地随着更理想的技术发展而变得可用。使用微服务，可以单独部署单个服务，但也可以单独扩展它们。由此产生的好处是显而易见的：如果做得正确，微服务比单体应用程序需要更少的基础设施，因为它们只支持对需要它的组件进行精确扩展，而不是在单体应用程序的情况下对整个应用程序进行扩展。微服务的显着优势伴随着重大挑战。从单体架构到微服务意味着更多的管理复杂性——更多的服务，由更多的团队创建，部署在更多的地方。一项服务中的问题可能会导致或由其他服务中的问题引起。日志数据（用于监控和解决问题更加庞大，并且在服务之间可能不一致。新版本可能会导致向后兼容性问题。应用程序涉及更多的网络连接，这意味着出现延迟和连接问题的机会更多。DevOps方法可以解决其中的许多问题，但DevOps的采用也有其自身的挑战。然而，这些挑战并没有阻止非采用者采用微服务——或者采用者深化他们的微服务承诺。新的IBM调查数据显示，%的当前非用户可能或非常可能在未来两年内采用微服务，%的当前微服务用户可能会增加他们在微服务上投入的时间、金钱和精力微服务架构通常被描述为针对DevOps和持续集成/持续交付(CI/CD)进行了优化，在可以频繁部署的小型服务的上下文中，原因很容易理解。但另一种看待微服务和DevOps之间关系的方式是，微服务架构实际上需要DevOps才能成功。虽然单体应用程序具有本文前面讨论过的一系列缺点，但它们的好处是它不是一个具有多个移动部件和独立技术堆栈的复杂分布式系统。相比之下，鉴于微服务带来的复杂性、移动部件和依赖项的大量增加，在部署、监控和生命周期自动化方面没有大量投资的情况下使用微服务是不明智的。虽然几乎任何现代工具或语言都可以在微服务架构中使用，但有一些核心工具已成为微服务必不可少的边界定义：微服务的关键要素之一是它通常非常小。（没有任意数量的代码可以确定某物是否是微服务，但名称中的“微”就在那里。当Docker在年迎来现代容器时代时，它还引入了与微服务最密切相关的计算模型。由于单个容器没有自己的操作系统的开销，它们比传统的虚拟机更小更轻，并且可以更快地启动和关闭，使其成为微服务架构中更小、更轻的服务的完美匹配.随着服务和容器的激增，编排和管理大量容器很快成为关键挑战之一。Kuberes是一个开源容器编排平台，已成为最受欢迎的编排解决方案之一，因为它做得非常好。微服务通常通过API进行通信，尤其是在首次建立状态时。虽然客户端和服务确实可以直接相互通信，但API网关通常是一个有用的中间层，尤其是当应用程序中的服务数量随着时间的推移而增长时。API网关通过路由请求、跨多个服务扇出请求以及提供额外的安全性和身份验证来充当客户端的反向代理。有多种技术可用于实现API网关，包括API管理平台，但如果使用容器和Kuberes实现微服务架构，则网关通常使用Ingress或最近的Istio来实现。虽然最佳实践可能是设计无状态服务，但状态仍然存在，服务需要了解它。虽然API调用通常是为给定服务初始建立状态的有效方式，但它并不是保持最新状态的特别有效方式。不断的轮询，“我们到了吗？”保持服务最新的方法根本不切实际。相反，有必要将建立状态的API调用与消息传递或事件流结合起来，以便服务可以广播状态的变化，而其他相关方可以监听这些变化并进行相应的调整。这项工作可能最适合通用消息代理，但在某些情况下，事件流平台（例如ApacheKafka可能更适合。通过将微服务与事件驱动架构相结合，开发人员可以构建分布式、高度可扩展、容错和可扩展的系统，可以实时消费和处理大量事件或信息。无服务器架构将一些核心云和微服务模式得出其合乎逻辑的结论。在无服务器的情况下，执行单元不仅仅是一个小服务，而是一个函数，它通常可以只是几行代码。将无服务器功能与微服务分开的界限很模糊，但通常认为功能比微服务还要小。无服务器架构和功能即服务(FaaS)平台与微服务的相似之处在于，它们都对创建更小的部署单元和根据需求精确扩展感兴趣。微服务不一定与云计算完全相关，但它们如此频繁地结合在一起有几个重要原因——这些原因超越了微服务成为新应用程序的流行架构风格以及云成为新应用程序的流行托管目的地的原因。微服务架构的主要优势之一是与单独部署和扩展组件相关的利用率和成本优势。虽然这些优势在一定程度上仍然存在于本地基础设施中，但小型、独立可扩展的组件与按需、按使用付费的基础设施相结合是可以找到真正成本优化的地方。其次，也许更重要的是，微服务的另一个主要好处是每个单独的组件都可以采用最适合其特定工作的堆栈。当您自己管理堆栈扩散时，可能会导致严重的复杂性和开销，但是将支持堆栈作为云服务使用可以大大减少管理挑战。换句话说，虽然推出自己的微服务基础设施并非不可能，但不可取，尤其是刚开始时。在微服务架构中，有许多常见且有用的设计、通信和集成模式有助于解决一些更常见的挑战和机遇，包括：例如，在桌面上使用的应用程序将具有与移动设备不同的屏幕尺寸、显示和性能限制。BFF模式允许开发人员使用该界面的最佳选项为每个用户界面创建和支持一种后端类型，而不是尝试支持适用于任何界面但可能会对前端性能产生负面影响的通用后端。例如，在电子商务网站上，产品对象可能通过产品名称、类型和价格来区分。聚合是应被视为一个单元的相关实体的集合。因此，对于电子商务网站，订单将是买家订购的产品（实体的集合（集合。这些模式用于以有意义的方式对数据进行分类。在微服务架构中，服务实例会因伸缩、升级、服务故障甚至服务终止而动态变化。这些模式提供了发现机制来应对这种短暂性。负载平衡可以通过使用健康检查和服务故障作为重新平衡流量的触发器来使用服务发现模式。适配器模式的目的是帮助翻译不兼容的类或对象之间的关系。依赖第三方API的应用程序可能需要使用适配器模式来确保应用程序和API可以通信。这个色彩缤纷的名字指的是藤蔓（微服务如何随着时间的推移慢慢地超越并扼杀一棵树（单体应用程序。虽然有很多模式可以很好地完成微服务，但同样数量的模式可以很快让任何开发团队陷入困境。其中一些——改写为微服务“不要”——如下：一旦应用程序变得太大且难以轻松更新和维护，微服务是一种管理复杂性的方法。只有当您感觉到单体架构的痛苦和复杂性开始蔓延时，才值得考虑如何将该应用程序重构为更小的服务。在你感受到那种痛苦之前，你甚至没有真正拥有需要重构的单体。尝试在没有a)适当的部署和监控自动化或b)托管云服务来支持您现在庞大的异构基础设施的情况下进行微服务，会带来很多不必要的麻烦。省去你自己的麻烦，这样你就可以把时间花在担心状态上。最好倾向于更大的服务，然后只在它们开始开发微服务解决的特征时才将它们分开——即部署更改变得困难和缓慢，通用数据模型变得过于复杂，或者不同部分服务有不同的负载/规模要求。微服务和SOA之间的区别在于，微服务项目通常涉及重构应用程序以便更易于管理，而SOA关注的是改变IT服务在企业范围内的工作方式。一个演变成SOA项目的微服务项目可能会因自身的重量而崩溃。你最好从一个你可以处理的速度开始，避免复杂性，并尽可能多地使用现成的工具。
分钟搞懂分布式架构与微服务
所谓分布式系统，是指一个完整的应用系统被拆分后，分别部署到不同的网络节点中，这样的系统往往是一些大型的系统。这种做法的好处是，可以提高系统的运算能力。与分布式系统相对应的就是单体应用系统，单体应用系统的思想是allinone思想，就是全部在一起，一个系统的全部服务都集中在一个网络节点上。所谓集群就是，相同的事情多个人做，比如在上图分布式系统中，**商品服务**被部署到一台机器上，但是如果在购物节时，请求太多，一台机器根本扛不住，这时我们也增加台机器，这台机器都部署**商品服务,**这样由这台机器就组成了商品服务集群，集群的初衷就是提高系统的吞吐量，另一个就是提高可用性，比如一台服务器挂了，不至于服务不可用。SOA架构就是面向于服务的架构思想，本质上就是以服务为中心，把应用拆分为多个服务，抽离出可重用的服务，为每个服务的单独扩展和开发提高便利性。阿里的Dubbo就是SOA服务架构的一种实现，事实上SOA并没有对服务间通信协议具体规定，可以RPC,可以HTTP。微服务是一种SOA思想的延续，任然关注服务，但是强调是“微“,微体现的是服务开发成分要低，职责要尽量单一，同时部署也要灵活方便。目前微服务是非常流行的一种软件架构，在Java生态中SpringCloud就提供了微服务的全站解决方案。分布式和集群都是从软件部署的角度描述，SOA与微服务是从软件的架构阐述。一个采用SpringCloud技术开发系统必然是微服务，当然同时也是分布式系统，当然如果为了高可用，必定也采用集群。
微服务对redis版本有要求吗
没有要求。经查询Redis版本的相关资料得知，Redis版本可以广泛用于微服务架构中，所以微服务对redis版本没有要求。微服务是一种软件开发技术-面向服务的体系结构（SOA架构样式的一种变体。
jee和微服务架构区别
二者是本质上的区别。、微服务与SOA之间的另一个不同之处是服务互联和编写服务时所使用的技术。、JEE是一个遵循企业级标准的用于编写SOA架构的技术栈。