架构设计之「 微服务入门 」

微服务这几年不可谓不火,很多技术团队都开始在自己的项目上引入了微服务。一方面这些团队确实很好的推动了微服务的应用和发展,另一方面也可以看到一些盲目追技术热点的行为所带来的危害,比如很多中小团队对微服务的基础知识只是做了很浅显的了解就开始盲目的推动微服务的实施,最后导致了项目的失败。

微服务要想做好是一个非常复杂的架构,今天就先只聊一聊微服务的一些基础架构,算是入门篇。

一、什么是「 微服务 」?

「 微服务 」由 Martin Fowler 提出,它是指一种软件架构风格。一个大型的系统可以由多个微服务组成,每个微服务是被独立部署,独立完成自己的任务单元,微服务之间是通过API方式进行通信调用,是松耦合的。

这个模式听着是不是很熟悉的感觉?

因为在提出「 微服务 」概念之前,很多互联网公司的中大型项目早就是按照将业务拆分成独立单元的形式在部署和架构的,这与微服务的思路是一脉相通的,只不过实现方式没有现在这么规范与体系。

那「 微服务 」到底是怎么演变过来的呢?

在做一个新项目的时候,一开始项目大多数都很小,都是「 单体应用 」,这是很常见的做法。在项目规模小的时候,这种方式开发效率和运维效率都最高,符合互联网公司快速响应的要求。

但是随着业务量越来越大,项目也越来越复杂,开发团队人员也越来越多。这个时候还采用单体应用,问题就会很明显了。下面挑选两个最为常见的问题来举例:

  • 协同问题:多个人同时开发一份代码,在工作协同上就会经常遇到代码冲突问题。
  • 可用性问题:因为是单体应用,即使改个最小的功能,也需要整体发布,不仅直接影响了线上可用性,还可能会对正常功能带来风险。

为了解决这些问题,大家就开始考虑将「 单体应用 」进行拆分,进行服务化部署。然后又随着 Martin Fowler对「 微服务 」概念的提出,加上 DevOps 的流行,进一步促进了微服务的火热发展。

「 微服务 」的理念提倡每个服务都是单一职责,且每一个服务都能实现自治,因此可以带来一些明显好处:

  • 部署简单:每个微服务都可以独立去部署,方便快捷。
  • 逻辑清晰:将一个独立功能逻辑封装在单一微服务里面,实现整体项目的逻辑清晰。
  • 可扩展:因为可以随时增加和减少微服务,可以很方便的扩展功能。
  • 可靠性高:某一个功能的异常可以隔离在单一微服务里面,可以提高整体可靠性。

二、「 微服务 」的架构是什么样?

我们先来看一下「 微服务 」的架构图:

(图片来源网络,粉丝太少就懒得画图了,大家发挥一下想象力将就的看看,哈哈)

看起来挺复杂对不对,事实上也确实很复杂。

所以微服务并不是适用于所有项目、所有团队的。在应用之前一定要搞清楚是否适合自己。

要保证这么一套微服务架构能成功运行起来,我们起码需要以下这些 微服务的基础组件

  • 服务注册

    部署了一个微服务节点,得让调用者知道啊,当微服务节点有增加或减少的时候,也得让调用者及时知晓啊。这些问题都是通过“服务注册”组件来实现的,服务提供者将自己的服务地址等信息登记到“服务注册”组件中,调用者需要的时候,每次都先去查询“服务注册”即可。免去人工维护微服务节点的信息同步问题。

  • 服务网关

    是指提供给外部系统调用的是统一网关。主要做安全和权限控制等。

  • 配置中心

    微服务的配置中心是用来统一管理所有微服务节点的配置信息的。因为同一个程序可能要适用于多个环境,所以在微服务实践中要尽量做到程序与配置分离,将配置进行集中管理。包括微服务节点信息、程序运行时配置、变量配置、数据源配置、日志配置、版本配置等。

  • 服务框架

    是指用来规范各个微服务节点之间通信标准的。服务间通信采用什么协议、数据是如何传输的、数据格式是什么样的。有了这个统一的“服务框架”就能保证各个微服务节点之间高效率的协同。

  • 服务监控

    微服务运行起来之后,为了能够监控节点的健康情况,保障节点的高可行,需要对各个服务节点进行收集数据指标、然后对数据进行实时处理和分析,形成监控报表和预警。

  • 服务追踪

    一旦使用了微服务架构,那么当有请求过来时,就会经过多个微服务节点的处理,形成了一个调用链。为了进行问题追踪和故障的定位,需要对请求的完整调用链进行记录。

    这里的服务追踪与上面的服务监控是不同维度的,一个是全局的,一个是微观的,发挥的作用也不一样。

  • 服务治理

    就是指需要通过准备一些策略和方案,来保障整个微服务架构在生产环境遇到极端情况下也能正常提供服务的措施。比如 熔断、限流、隔离等等。

当然,上述只是一个微服务架构最为核心的基础组件,一旦微服务体系过大,例如有几十上百个微服务节点,那么开发、维护、测试的成本就会非常大。因此一般还会引入 自动化部署 和 自动化测试 来提高协同效率。

三、「 微服务 」入门如何避免踩坑?

你以为微服务架构都是下面这样的吗?

事实上,更能是下面这样的,哈哈。

(图片来源网络)

大家都在宣扬「 微服务 」多么多么的好,例如:易扩展、松耦合、服务简单、独立开发、易维护、轻量级等等。虽然这些优势也是事实,但是「 微服务 」带来的问题也很多,尤其是对于刚入门的团队而言,应用微服务后,趟坑真的可以趟到你崩溃。下面就普及一些常见的问题来给大家打个预防针:

  • 不是所有项目都适用微服务

    有些项目规模还比较小,或者项目才刚立项启动,也只有三四个人负责开发维护,这时候是不建议一上来就搞微服务架构的。这种情况下搞微服务,不仅是“杀鸡用牛刀”,而且还无谓的增加了项目的复杂度,本身一个单体结构就可以搞定的事情,非得拆分N多节点,人员又不足以支撑这么多节点的开发维护,这完全是自找苦吃。反而是等项目成熟了、规模大了之后,再开始慢慢将原有结构拆为微服务才是正确的做法。

  • 不要拆分过多过细的服务

    即使项目经过评估后适合拆为微服务架构,但也不要过度拆解。有的团队喜欢将项目拆成很细很细的颗粒,最后把项目搞的特别复杂,整个团队都陷进去了。

    拆分服务的颗粒度应该根据业务发展和团队现状综合去考虑。这里可以参考一个很火的理论「 康威定律 」。什么样的团队,就产生什么样的架构,微服务拆分的颗粒度是需要和团队结构相匹配的。当你着手拆微服务的时候,得先评估一下团队人员和素质,一般在开发期,2-3个人开发一个服务是合理的,在维护期,1个人维护2-3个服务也是合理的。

    如果拆分过细,开发人员跟不上,会严重降低大家的工作效率。并且过细的服务,会导致一个请求的调用链条很长,不仅会影响请求的响应时间,也会对线上问题排查带来增加难度。

  • 没有DevOps就不要急于微服务

    一个稳定的微服务架构,是需要 持续集成、自动化部署、自动化测试、健全的监控体系来保障的。如果团队还不具备DevOps,这些基础的建设都没有做好,一上来就搞微服务的话,就会导致实施过程中问题百出,微服务的优势不能发挥。

以上,就是对架构设计中「 微服务基础 」的一些思考。

原文地址:https://www.cnblogs.com/SimpleWu/p/10612478.html

时间: 2024-10-04 17:25:20

架构设计之「 微服务入门 」的相关文章

Atitit.架构设计趋势 设计模式 ---微服务架构  soa

Atitit.架构设计趋势 设计模式 ---微服务架构  soa 什么是微服务架构?1 .微服务与SOA的关系 :微服务架架构师面向服务架构(SOA)的一种特定实现1 微服务与康威定律2 微服务的一些设计 断路器 幂等2 <微服务设计>([英] 纽曼(Sam Newman))3 微服务架构与实践4 什么是微服务架构? Martin Fowler认为,微服务架构是一种独立部署的软件应用设计方式.这种架构方式没有准确的定义,但是在业务能力.自动部署.端对端的整合.对语言及数据的分散控制上有着共性.

架构演进之「微服务架构」

"为什么要搞「微服务架构」"?这也是我们当初讨论的聚焦点.现在天天把"微服务"挂在嘴边的人很多,但是有多少人真正深入思考过"为什么",我认为可能不多. 于是我在梳理材料的时候,就决定从源头入手--即"为什么". 架构是演进的,不是一蹴而就. "架构演进趋势图"中的趋势分析,在业界比较公认.这个图本身的内容.关于各个架构的描述.优缺点等等,网上简单搜索一下有大把大把的,感兴趣的同学可以自行搜索,毕竟这也不是我

唯品会、滴滴、沪江架构师,关于微服务粒度、高可用、持续交互的实践分享交流(下)

架构师小组交流会:每期选择一个时下最热门的技术话题进行实践经验分享. 本期小组交流会邀请到了沪江黄凯.唯品会郑明华.滴滴赵伟.七牛云肖勤,对微服务粒度.高可用.持续交互展开了交流. 本期接着上期唯品会.滴滴.沪江架构师,关于微服务粒度.高可用.持续交互的实践分享交流(上)进行了交流. 第一轮:话题交流 滴滴赵伟:在整个服务,从单体服务到微服务的演进过程当中,如何去影响业务的这种正常发展? 唯品会郑明华:从单体服务到微服务的改造,有两种方式,一种是小打小闹,每次稍微改一点,这个时间会非常长,有时候

百度“百老汇”架构师深刻透视微服务架构

首先解释这个"百老汇"=百度老年架构师活动中心.......什么是微服务首先微服务并没有一个官方的定义,想要直接描述微服务比较困难,我们可以通过对比传统WEB应用,来理解什么是微服务.传统的WEB应用核心分为业务逻辑.适配器以及API或通过UI访问的WEB界面.业务逻辑定义业务流程.业务规则以及领域实体.适配器包括数据库访问组件.消息组件以及访问接口等.一个打车软件的架构图如下: 尽管也是遵循模块化开发,但最终它们会打包并部署为单体式应用.例如Java应用程序会被打包成WAR,部署在T

Re:从 0 开始的微服务架构--(四)如何保障微服务架构下的数据一致性--转

原文地址:http://mp.weixin.qq.com/s/eXvoJew3bjFKzLLJpS0Otg 随着微服务架构的推广,越来越多的公司采用微服务架构来构建自己的业务平台.就像前边的文章说的,微服务架构为业务开发带来了诸多好处的同时,例如单一职责.独立开发部署.功能复用和系统容错等等,也带来一些问题. 例如上手难度变大,运维变得更复杂,模块之间的依赖关系更复杂,数据一致性难以保证,等等.但是办法总是比问题多,本篇文章就来介绍一下我们是如何保障微服务架构的数据一致性的. 微服务架构的数据一

架构设计之「服务限流」

上一篇我们聊过了架构设计中的「服务隔离」模式,今天我们继续来探索一下在分布式系统架构中的另一个常用的设计:服务限流.那么,什么是「服务限流」呢? 在解释「服务限流」之前,我们来看一下前些时间网上很火的一个段子,说的是新浪微博的一名工程师正在家里办婚礼,突然接到公司的电话要紧急处理线上流量激增的问题,那天应该是某当红明星突然在微博上公布恋情,微博流量突增好几倍,导致系统功能出现不稳定,用户访问不畅.然后这名工程师就只好晾开新娘,在婚礼现场穿着西装打开笔记本调试代码了.当时这名工程师内心肯定是崩溃的

架构设计之「数据库集群方案」

在之前的文章中,我们知道数据库服务可能已经成为了很多系统的性能关键点,甚至是瓶颈了.也给大家介绍了数据库服务器从主备架构.到主从架构.再到主主架构的基础方案.但如果单台机器已经不能满足完整业务数据存储的时候,我们就需要考虑采用多机甚至多中心的部署方案了. 今天我们就再来聊一聊,在多机环境下,数据库集群的架构方案. 同样,这里先不看细节,不管底层数据源是什么数据库,我们先谈架构方案.因为无论底层是 Mysql 还是 Redis.MongoDB,我们在架构设计上都是相通的. 针对多机的架构,常见有如

想要设计自己的微服务?看这篇文章就对了

欢迎大家前往腾讯云+社区,获取更多腾讯海量技术实践干货哦~ 本文由我就静静地看发表于云+社区专栏 本文通过使用Spring Boot,Spring Cloud和Docker构建的概念验证应用程序的示例,为了解常见的微服务架构模式提供了一个起点. 该代码在Github上可用,并且可以在Docker Hub上获得图像.只需一个命令即可启动整个系统. 作为这个系统的基础,我选择了一个旧项目,其后端曾经是一个整体.该应用程序提供了一种处理个人财务,组织收入和支出,管理储蓄,分析统计数据和创建简单预测的方

使用Istio治理微服务入门

近两年微服务架构流行,主流互联网厂商内部都已经微服务化,初创企业虽然技术积淀不行,但也通过各种开源工具拥抱微服务.再加上容器技术赋能,Kubernetes又添了一把火,微服务架构已然成为当前软件架构设计的首选.但微服务化易弄,服务治理难搞! 一.微服务的"痛点" 微服务化没有统一标准,多数是进行业务领域垂直切分,业务按一定的粒度划分职责,并形成清晰.职责单一的服务接口,这样每一块规划为一个微服务.微服务之间的通信方案相对成熟,开源领域选择较多的有RPC或RESTful API方案,比如