微服务-概念术语
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了微服务-概念术语,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含3208字,纯文字阅读大概需要5分钟。
内容图文
什么是微服务架构
在网络协议的 RPC 协议部分,我们已经简单介绍了微服务诞生的原因,以及底层 RPC 框架的运行原理,今天开始,我们正式开始微服务架构分享之旅,在此之前,我们需要明确微服务架构的概念。
微服务 vs 服务化
其实在微服务之前,还有服务化的概念,主要应用在 Java 项目中,把传统单机应用通过 JAR 包依赖产生的本地方法调用,改造成通过 RPC 接口产生的远程方法调用,不同的功能模块拆分成独立的服务模块单独部署,以 RPC 接口的形式对外提供服务,这些拆分后的服务模块也是单独开发、测试、部署和运维的。看起来服务化已经解决了单体应用的问题,为什么还会出现微服务呢?
微服务其实是服务化的延伸,从 2014 年开始,得益于以 Docker 为代表的容器化技术的成熟以及 DevOps 文化的兴起,服务化的思想进一步演化,演变为今天我们所熟知的微服务。
那么微服务相比于服务化又有什么不同呢?大体可以总结为以下四点:
- 服务拆分粒度更细:微服务可以说是更细维度的服务化,小到一个子模块,只要该模块依赖的资源与其他模块都没有关系,那么就可以拆分为一个微服务;
- 服务独立部署:每个微服务都严格遵循独立打包部署的准则,互不影响,比如一台物理机上可以部署多个 Docker 实例,每个 Docker 实例可以部署一个微服务的代码;
- 服务独立维护:每个微服务都可以交由一个小团队甚至个人来开发、测试、发布和运维,并对整个生命周期负责;
- 服务治理能力要求高:因为拆分为微服务之后,服务的数量变多,因此需要有统一的服务治理平台,来对各个服务进行管理。
微服务架构的定义
其实从业界的讨论来看,微服务本身并没有一个严格的定义。不过,ThoughtWorks 的首席科学家 Martin Flowler 的描述更加通俗易懂:
微服务架构是一种架构模式,它提倡将单一应用程序划分成一组小的服务,服务之间互相协调、互相配合,为用户提供最终价值。每个服务运行在其独立的进程中,服务和服务间采用轻量级的通信机制互相沟通(通常是基于 HTTP 的 RESTful API)。每个服务都围绕着具体业务进行构建,并且能够被独立地部署到生产环境、类生产环境等。另外,应尽量避免统一的、集中式的服务管理机制,对具体的一个服务而言,应根据业务上下 文,选择合适的语言、工具对其进行构建。
—— 摘自马丁·福勒先生的博客,微服务的概念最早即来源于此。
微服务架构的特征
1、多微才够微
微服务架构通过对特定业务领域的分析与建模,将复杂的应用分解成小而专一、耦合度低并 且高度自治的一组服务,每个服务都是很小的应用。
微服务的「微」并不是一个真正可衡量、看得见、摸得着的微。这个「微」所表达的,是一种设计思想和指导方针,是需要团队或者组织共同努力找到一个平衡点。所以,微服务到底有多微,是个仁者见仁,智者见智的问题,最重要的是团队觉得合适。但注意,如果达成「团队觉得合适」的结论,至少还应遵循以下两个基本前提:
- 业务独立性:首先,应保证微服务是具有业务独立性的单元,并不能只是为了微而微;
- 团队自主性:其次,考虑到团队的沟通及协作成本,一般不建议超过10人。当团队超过10人,在沟通,协作上所耗费的成本会显著增加,这也是大部分敏捷实践里提倡的。
2、单一职责
所谓高内聚,是一个模块内各个元素彼此结合的紧密程度高。低耦合,是指对于一个完整的系统,模块与模块之间,尽可能独立存在。
在面向对象的设计中,更是有放之四海而皆准的「SOLID原则」。SOLID 原则中的 S 表示的是 SRP(Single Responsibility Principle,单一职责原则):即一个对象应该只有一个发生变化的原因,如果一个对象可被多个原因改变,那么就说明这个对象承担了多个职责。
对于每个服务而言,我们希望它处理的业务逻辑能够单一,在服务架构层面遵循单一职责原则。也就是说,微服务架构中的每个服务,都是具有业务逻辑的,符合高内聚、低耦合原则以及单一职责原则的单元,不同的服务通过「管道」的方式灵活组合,从而构建出庞大的系统。
3、轻量级通信
服务之间应通过轻量级的通信机制,实现彼此之间的互通互联,互相协作。所谓轻量级通信机制,通常指语言无关、平台无关的交互方式。
对于轻量级通信格式而言,我们熟悉的 XML 或者 JSON ,它们的解析和使用基本与语言无关、平台无关。对于轻量级通信协议而言,通常基于HTTP,能让服务间的通信变得标准化并且无状态化。 REST(Representational State Transfer,表现层状态转化),是实现服务之间互相协作的轻量级通信机制之一。
对于微服务而言通过使用语言无关、平台无关的轻量级通信机制,使服务与服务之间的协作变得更加标准化,也就意味着在保持服务外部通信机制轻量级的情况下,团队可以选择更适合的语言、工具或者平台来开发服务本身。
4、独立性
独立性是指在应用的交付过程中,开发、测试以及部署的独立。
在传统的单体架构应用中,所有功能都存在于同一个代码库中。当修改了代码库中的某个功能,很容易出现功能之间相互影响的情况。尤其是随着代码量、功能的不断增加,风险也会逐渐增加。
除此之外,当多个特性被不同小组实现完毕,需要经过集成、回归测试,团队才有足够的信心,保证功能相互配合、正常工作并且互不影响。因此,测试过程不是一个独立的过程。
当所有测试验证完毕,单体架构应用将被构建成一个部署包,并标记相应的版本。在部署过程中,单体架构部署包将被部署到生产环境,如果其中某个特性存在缺陷,则有可能导致整个部署过程的失败或回滚。、
单体应用开发、测试、构建、部署流程图如下:
在微服务架构中,每个服务都是一个独立的业务单元,当对某个服务进行改变时,对其他的服务不会产生影响。换句话说,服务和服务之间是独立的。对于每个服务,都有独立的代码库。当对当前服务的代码进行修改后,并不会影响其他服务。从代码库的层面而言,服务与服务是隔离的。
对于每个服务,都有独立的测试机制,并不担心破坏其他功能而需要建立大范围的回归测试。由于构建包是独立的,部署流程也就能够独立,因此服务能够运行在不同的进程中。
微服务开发、测试、构建、部署流程图如下:
5、进程隔离
所有功能运行在同一个进程中,也就意味着,当对应用进行部署时,必须停掉当前正在运行的应用,部署完成后,再重新启动进程,无法做到独立部署。如果当前某应用中包含定时任务的功能,则要考虑在什么时间窗口适合部署,是否先停掉消息队列或者切断与数据源的联系,以防止数据被读入应用程序内存,但还未处理完,应用就被停止而导致的数据不一致性。
为了提高代码的重用以及可维护性,在应用开发中,我们有时也会将重复的代码提取出来,封装成组件(比如 PHP 中的 Composer 扩展包)。在传统的单体架构应用中,当应用程序在运行期时,所有的组件最终也会被加载到同一个进程中运行。
在微服务架构中,应用程序由多个服务组成,每个服务都是一个具有高度自治的独立业务实体。通常情况下,每个服务都能运行在一个独立的操作系统进程中,这就意味着不同的服务能非常容易的被部署到不同的主机上。作为运行微服务的环境,我们希望它能够保持高度自治性和隔离型。如果多个服务运行在同一个服务器节点上,虽然省去了节点的开销,但是增加了部署和扩展的复杂度。
总而言之,微服务架构其实是将单一的应用程序划分成一组小的服务,每个服务都是具有业务属性的独立单元,同时能够被独立开发、独立运行、独立测试以及独立部署。
微服务架构总体设计和基础组件
微服务的优缺点和适用场景
服务拆分与技术保障
原文:https://www.cnblogs.com/stringarray/p/12945270.html
内容总结
以上是互联网集市为您收集整理的微服务-概念术语全部内容,希望文章能够帮你解决微服务-概念术语所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。