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

栏目: 后端 · 发布时间: 6年前

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

“为什么要搞「微服务架构」”?这也是我们当初讨论的聚焦点。现在天天把“微服务”挂在嘴边的人很多,但是有多少人真正深入思考过“为什么”,我认为可能不多。 于是我在梳理材料的时候,就决定从源头入手——即“为什么”。

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

架构是演进的,不是一蹴而就。

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

“架构演进趋势图”中的趋势分析,在业界比较公认。这个图本身的内容、关于各个架构的描述、优缺点等等,网上简单搜索一下有大把大把的,感兴趣的同学可以自行搜索,毕竟这也不是我们文章的重点。

软件发展的不同时期、阶段,对技术的理解、选择和应用都有着不一样的诉求。架构的选型,永远只有“合适与不合适”,永远没有“哪个更好”的说法。我们今天来谈论微服务,并不是因为它更牛,而是经过谨慎分析,认为微服务的思想更符合我们的目标。 什么是「微服务架构」?

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

既然聊的是“为什么”,那么首先要明白“什么是”。 「一解释就懂,一问就不知,一讨论就打架」,这是之前我在网上看到的一句话,笑了好久,太贴切了,就搬了过来。

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

提到微服务,就没法不提到这位“大神”——马丁·福勒,他没有直接给微服务下一个精准的定义,而是给出了微服务特点的描述,大概从以下四个方面来说:

1.根据业务模块划分服务种类

2.每个服务可以独立部署并且互相隔离

3.通过轻量的API调用服务

4.服务需要保证良好的高可用性

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

怎么理解呢?以下是我的解读:

第一点,按业务拆分服务,这是“水平拆分”;在技术层面的“前后分离”,属于“垂直拆分”;横纵一起切,就把单一的应用拆分成网状的小块应用,这是微服务中「微」思想的体现。

第二点,独立部署与互相隔离,这点充分体现了“我为人人、人人为我”的设计理念,这是微服务中「服务」思想的体现。

第三点,关于轻量API,微服务本身是推荐使用轻量的通讯协议和简单的数据结构,实际上,实施环节通常采用的都是http+json的方式。这样做的好处是,服务之间不再需要关心对方的模型,仅通过事先约定好的接口来进行数据流转即可。这是微服务中「解耦」思想的体现。

最后一点,比较通用了,就是现如今各种设计都必须考虑的事情。

于是,我给微服务下了一个定义(如图)。

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

在实际工作中,我们遇到过各式各样的问题,有些是技术问题,有些是业务问题,还有些是管理问题,这里拿其中一个案例来说一下。

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

这种事情说大不大,说小不小。其中最麻烦的事情是“推诿”的发生。每个独立组织都有自己的考核指标和关注点,而实际情况又不可能把具体的一个任务的界限划分得特别清晰。例如接口定义,哪怕说的是“双方坐下来一起商讨决定”,最终还是会有一方对此事负责,推诿在所难免。

微服务的指导思想其中一块就是关于组织机构调整的,这还有个专门的定律叫“康威定律”,感兴趣的可以自行搜索了解。

我们的解决办法也很有效果。在组织机构没有完全按照微服务的理念重新规划之前,这类需要跨组织协同完成的任务,直接成立临时项目组:相关的部门出人的出人、出资源的出资源,指定/选拔一个能hold住的项目经理对整件事情负责,然后大家惊奇的发现:“部门墙”问题不见了,因为所有事情都是组内事情了,整体的完成情况跟全部项目组成员的业绩都挂钩了,事情推进就非常顺利。在顺利交付之后,项目组解散,各回各家。极大的提升了沟通效率、交付速度,同时使得资源利用率也得到了很大的提升。

其实很多时候,大家解决问题的想法和思路,并不是要有了微服务才这样做,而是“不谋而合”,微服务就存在于我们日常工作的点点滴滴之中。

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

有人问:我要搞微服务了,有啥建议么?

有的。通过我们不断的摸索和总结,要做好微服务,就要做好一定的准备工作,从四个具体的方面来谈:

业务拆分 – 体现在设计环节:在设计的时候,要有足够的判断力来合理的规划服务之间的界限。 服务治理 – 底层技术的支持:首先要选一款适合自己实际情况的分布式服务基础框架,对于服务的发现、治理、熔断、降级,都要做好相应的技术准备。

自动测试:一定要自动化。微服务一个明显的表象就是随着服务的增多,如果继续沿用传统的测试模式就会遇到瓶颈,为了保证高效的迭代,尽量做到更多的环节实现自动化。

自动运维 :微服务拆分之后,每个服务都可以独立部署,进而言之应该是随时随地可以升级。尤其当互联网发展到今天,业务要保持对市场变化的一个高效响应,自动化运维就是提升交付速度的一个重要环节。

最后一定要提的是「监控」:包括硬件环境、服务状态、系统健康度、接口调用情况、异常的实时告警以及潜在问题的事先预警等等。「监控」在实施微服务过程中会重要到什么程度呢?一句话:没准备好监控,就不要搞微服务。

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

最后,微服务不是银弹,软件领域没有银弹,微服务以其特有的优势在解决一些问题的同时,也引入了其他问题,这几点,必须要深刻的思考。

「三思而后行」。

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

——————————————————分割线——————————————————

我是小微,专注微服务技术分享,致力挖掘更多“高、精、全”的微服务知识分享给大家。

我的微信:weiweiweiblack (备注:掘金 )

微信公号:黑少微服务,“分享技术,热爱生活”,欢迎关注


以上就是本文的全部内容,希望本文的内容对大家的学习或者工作能带来一定的帮助,也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

本站部分资源来源于网络,本站转载出于传递更多信息之目的,版权归原作者或者来源机构所有,如转载稿涉及版权问题,请联系我们

Computer Age Statistical Inference

Computer Age Statistical Inference

Bradley Efron、Trevor Hastie / Cambridge University Press / 2016-7-21 / USD 74.99

The twenty-first century has seen a breathtaking expansion of statistical methodology, both in scope and in influence. 'Big data', 'data science', and 'machine learning' have become familiar terms in ......一起来看看 《Computer Age Statistical Inference》 这本书的介绍吧!

图片转BASE64编码
图片转BASE64编码

在线图片转Base64编码工具

MD5 加密
MD5 加密

MD5 加密工具

HSV CMYK 转换工具
HSV CMYK 转换工具

HSV CMYK互换工具