微服务概述之微服务特性

发布时间:2024年01月15日

前言

既然系统采用了微服务架构,就需要了解一些微服务的特性,这样在进行微服务开发时,脑海中才会有一些指导方向。微服务具有以下特性。

1. 服务组件化

组件是独立、可替换、可升级的软件的单元。将整体应用拆分成独立的服务组件后,当对单个组件的修改完成后,只需要重新部署该组件即可。这也不是绝对的,有一些改动会影响服务间的接口,调用方(消费者)也需要进行相应的修改与部署。所以好的微服务架构的目标是通过高内聚、低耦合来尽量减少不同服务之间的依赖。

2.围绕业务能力组织团队

康威定律指出:设计系统的架构,受制于产生这些设计的组织的沟通结构。不同公司的产品结构,基本上反映了组织的沟通结构,如图1-3所示。
在这里插入图片描述

在一个单体应用中,一个项目会有很多研发团队的人参与,如前端工程师组、后端工程师组、数据库管理员组,不同组的人参与同一个项目,彼此沟通成本很高。单体项目的分工图如图1-4所示。
在这里插入图片描述

在微服务项目中,团队是围绕业务来进行组织的。例如,某个服务组里有前端工程、后端工程师、数据库管理员,这算是一个工作单元,能极大降低沟通成本。

3. 产品不是项目

在大部分软件开发时,采用的都是项目的形式,开发团队开发完软件后将软件交给运维团队去维护,原来的项目团队解散。微服务支持者倾向于避免这种模式,他们认为团队应该在产品的整个生命周期内对它负责。这就是 Amazon(亚马逊)提出的“you build,you run it”。这么做的好处是可以让开发人员经常接触到他们的产品,从而了解产品在生产中的行为,并增加与用户的联系,同时在业务升级时也很方便,毕竟开发和升级都是由同一个团队负责。

4. 去中心化的数据管理

在单体应用中,数据都在一个数据库(这里指的是逻辑库,可能物理上部署多个数据库服务器)中,管理难度大。在微服务中,不同的业务数据是放到不同的服务所对应的数据库中的。
如订单存放到订单库、商品存放到商品库等,从而大大降低了数据的管理难度。去中心化数据库示例如图1-5所示。在这里插入图片描述

5. 分散治理

由于將大服务分成了小服务,所以每个服务都可以根据自己的需求,采用合适的技术实现方案,如采用不同的语言(有的业务适合用Go,有的业务适合用Java)、采用不同的存储(有的业务适合用Redis,有的业务适合用MySQL)等。这样更利于提高开发效率,节省资源。

总结

了解了微服务的特性,作为一名有着架构师梦想的程序员,应该清楚地认识到微服务可以给实际工作带来的好处。

  • 从公司团队管理角度。将服务拆分成微服务后,可以让独立的团队完成独立的服务,实现不同的业务,使得团队更聚焦,減少了跨部门沟通的障碍,大大提高了开发效率。
  • 从公司产品研发角度。由于服务彼此独立,可以针对不同的产品需求,针对不同的服务快速地进行产品升级。从而在快节奏的软件开发环境中,缩短对市场的响应时间,加快产品的迭代。
文章来源:https://blog.csdn.net/Wtzink/article/details/135589323
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。