从源头入手,一分钟秒懂为什么要搞微服务架构?

现在天天把“微服务”挂在嘴边的人很多,为什么要搞微服务架构?有多少人真正深入思考过“为什么”,我认为可能不多。

图片描述
于是我在梳理材料的时候,就决定从源头入手——即“为什么”。

图片描述
架构是演进的,不是一蹴而就
图片描述

“架构演进趋势图”中的趋势分析,在业界比较公认。这个图本身的内容、关于各个架构的描述、优缺点等等,网上简单搜索一下有大把大把的。
软件发展的不同时期、阶段,对技术的理解、选择和应用都有着不一样的诉求。架构的选型,永远只有“合适与不合适”,永远没有“哪个更好”的说法。我们今天来谈论微服务,并不是因为它更牛,而是经过谨慎分析,认为微服务的思想更符合我们的目标。
如果你想学好JAVA这门技术,想在IT行业拿高薪,可以参加我们的训练营课程,选择最适合自己的课程学习,技术大牛亲授,7个月后,进入名企拿高薪。我们的课程内容有:Java工程化、高性能及分布式、高性能、深入浅出。高架构。性能调优、Spring,MyBatis,Netty源码分析和大数据等多个知识点。如果你想拿高薪的,想学习的,想就业前景好的,想跟别人竞争能取得优势的,想进阿里面试但担心面试不过的,你都可以来,群号为:647631030
附:
加群要求
1、具有1-5工作经验的,面对目前流行的技术不知从何下手,需要突破技术瓶颈的可以加。
2、在公司待久了,过得很安逸,但跳槽时面试碰壁。需要在短时间内进修、跳槽拿高薪的可以加。
3、如果没有工作经验,但基础非常扎实,对java工作机制,常用设计思想,常用java开发框架掌握熟练的,可以加。
4、觉得自己很牛B,一般需求都能搞定。但是所学的知识点没有系统化,很难在技术领域继续突破的可以加。

什么是微服务架构?
图片描述

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

图片描述
提到微服务,就没法不提到这位“大神”——马丁·福勒,他没有直接给微服务下一个精准的定义,而是给出了微服务特点的描述。
大概从以下四个方面来说:
根据业务模块划分服务种类。
每个服务可以独立部署并且互相隔离。
通过轻量的 API 调用服务。
服务需要保证良好的高可用性。

图片描述
怎么理解呢?以下是我的解读:
按业务拆分服务,这是“水平拆分”;在技术层面的“前后分离”,属于“垂直拆分”;横纵一起切,就把单一的应用拆分成网状的小块应用,这是微服务中“微”思想的体现。
独立部署与互相隔离,这点充分体现了“我为人人、人人为我”的设计理念,这是微服务中「服务」思想的体现。
关于轻量 API,微服务本身是推荐使用轻量的通讯协议和简单的数据结构,实际上,实施环节通常采用的都是 http+json 的方式。
这样做的好处是,服务之间不再需要关心对方的模型,仅通过事先约定好的接口来进行数据流转即可。这是微服务中“解耦”思想的体现。
最后一点,比较通用了,就是现如今各种设计都必须考虑的事情。于是,我给微服务下了一个定义,如下图:
图片描述

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

这种事情说大不大,说小不小,其中最麻烦的事情是“推诿”的发生。每个独立组织都有自己的考核指标和关注点,而实际情况又不可能把具体的一个任务的界限划分得特别清晰。
例如接口定义,哪怕说的是“双方坐下来一起商讨决定”,最终还是会有一方对此事负责,推诿在所难免。
微服务的指导思想其中一块就是关于组织机构调整的,这还有个专门的定律叫“康威定律”。
我们的解决办法也很有效果,在组织机构没有完全按照微服务的理念重新规划之前,这类需要跨组织协同完成的任务,直接成立临时项目组:相关的部门出人的出人、出资源的出资源,指定/选拔一个能 hold 住的项目经理对整件事情负责。
然后大家惊奇的发现:“部门墙”问题不见了,因为所有事情都是组内事情了,整体的完成情况跟全部项目组成员的业绩都挂钩了,事情推进就非常顺利。
在顺利交付之后,项目组解散,各回各家。极大的提升了沟通效率、交付速度,同时使得资源利用率也得到了很大的提升。
其实很多时候,大家解决问题的想法和思路,并不是要有了微服务才这样做,而是“不谋而合”,微服务就存在于我们日常工作的点点滴滴之中。
图片描述

要搞微服务了,有啥建议么?通过我们不断的摸索和总结,要做好微服务,就要做好一定的准备工作。
从五个具体的方面来谈:
业务拆分,体现在设计环节:在设计的时候,要有足够的判断力来合理的规划服务之间的界限。
服务治理,底层技术的支持:首先要选一款适合自己实际情况的分布式服务基础框架,对于服务的发现、治理、熔断、降级,都要做好相应的技术准备。
自动测试,一定要自动化。微服务一个明显的表象就是随着服务的增多,如果继续沿用传统的测试模式就会遇到瓶颈,为了保证高效的迭代,尽量做到更多的环节实现自动化。
自动运维 :微服务拆分之后,每个服务都可以独立部署,进而言之应该是随时随地可以升级。尤其当互联网发展到今天,业务要保持对市场变化的一个高效响应,自动化运维就是提升交付速度的一个重要环节。
监控:包括硬件环境、服务状态、系统健康度、接口调用情况、异常的实时告警以及潜在问题的事先预警等等。监控在实施微服务过程中会重要到什么程度呢?一句话:没准备好监控,就不要搞微服务。
图片描述

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

图片描述
微信搜索 关注JAVA高级架构 公众号,有你意想不到的惊喜哦!

  • 0
    点赞
  • 1
    收藏
    觉得还不错? 一键收藏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值