微服务|微服务总述|学习方法|总结的方法

Updated on with 401 views

开头说两句

小刀博客:https://www.lixiang.red
小刀公众号:程序员学习大本营

技术背景

当下时节,大家都在聊着微服务,而且各种名词张口就来,适时,老师在群里面发起了微服务的相关讨论,借着大家的智慧,小刀也来聊一聊微服务

什么是微服务

在了解什么是微服务之前,我们要先知道微服务的演进背景:单体架构->SOA->微服务,这些其实小刀并不想说,因为这些去百度一搜,都是一大把,早就被人讲烂了,小刀想说的是,天下大势,合久必分,分久必合!
不说这么大,单就是我们自己写代码,先都是在一个函数,然后写个几百行,然后开始分到不同的函数,然后分到不同的类,然后分到不同的jar包。 这是从技术方面的演变
但是我们的类并不都是平铺的,我们把平铺的类入到同一个package下,把相关的package放到同一个jar下面,把入口应用迁移到单独的jar里面。 这是从业务方面的演变
微服务, 技术和业务一个都不能少!
相对于大家都在谈微,小刀更想和大家聊一聊服务这个词。近期接触到的服务概念还有k8s上的服务。一个k8s的服务,有一个端口做门户,能接受收入,能返回结果,服务内部,我们就可以当做一个黑盒子。那以类比于微服务, 我们也可以看成,通过一个url/方法 ,给他参数,然后能拿到结果,就可以把它当做一个微服务。 或者你和小刀说一句话,小刀回你一颗糖,这时,也可以把小刀当做一个微服务

微服务的价值

小刀的糖糖好不好吃? 不好吃? 那小刀的文章好不好看? 如果,小刀因为做别的事半天才忙过来给你发糖呢,,,毕竟小刀就一张嘴,两只手(1核2G?)
在以前学算法时,有句话说是,要不就是拿空间换时间,要不就是拿时间换空间,二者难全矣!
做为一个商人来看,天下熙熙皆来利来,天下攘攘,皆为利往,这么多人对微服务趋之若鹜,那微服务肯定是能带给我们利的。
小刀看来,微服务的利在于用廉价的空间换来了宝贵的时间。
喂喂,别走啊,那个,要领糖的啊,请往这边走,找我们的花音小姐姐可以快速领糖。
看,一张嘴两只手不够,我们就再加一台, 这边小刀就负责和大家聊聊天,花音小姐姐负责给大家发糖,业务划分清晰,快速响应请求。而且我可以站着聊,躺着聊,小姐姐可以坐着发糖,顺时针发,逆时针发。 我们两个高度自治,互补影响。说到这,突然想到,如果有人问微服务的好处我们就可以反问一句,有没有打过王者荣耀啊,会不会打团啊

微服务的实践

这一块其实没打算聊dubbo , springcloud , zuul , eurake等等,还是那句话,这些百度上一找,都是一大堆的教程,小刀想和大家聊一聊微服务的内功:如第一段所说,微服务,技术和业务一个都不能少!
从技术上来说,不说了,开头就说这些不说了,不不,开头那些只是技术的表现,实际上,那些都可以划分为基础支持服务。在基础支持服务之外,还有业务应用组,运维支持组. 每组都有自己的技术组合,但大致的思路都是一样的,这里小刀想强调思路这两字. 如我们在装修房子时,装个1W的门也是门,装个几百的门也是装,都是门. 区别不是特别的大,但是有门和没门的区别就大了.如我们本文讨论的是得有什么,不是用什么,具体用什么可以在大体框架设计出来之后,再慢慢根据业务量,适用场景选型.那我们需要哪些组件呢,网关,注册服务器,全局监控,等等这些在百度上就很多文章在讲了
从业务上来讲, 最难的就是定义微服务的界限,关于业务,现在大家都在谈领域驱动,有四色建模系统的方法来对领域驱动建模,感兴趣的小伙伴可以百度一下,小刀也写过几篇关于领域驱动文章,也可一起讨论交流:
架构设计-商品模块的领域驱动设计思路及实现https://www.lixiang.red/articles/2019/07/25/1564025186602.html
从零开始领域驱动-划分代码层次https://www.lixiang.red/articles/2019/07/23/1563896973689.html
在下面的总结方法中,也对划分层次有些涉及,世间万物相通,领域驱动不是一个专门的学问,如我们研究游戏打法时,把一些专业名词一换,也可以摇身一变,变成游戏攻略领域的研究.

小刀的总结方法

在以往的文章中,我们隔三差五的,都会提一些学习方法,今天我们聊一下总结的方法。
有句话说是:每日三省吾身。总结这个事,我们一直都在进行中,且在不断的实践中。 但实际上我们的总结大都是停留在把我们做的事,接收到的信息过一遍,很难有下一步的行为。小刀一直都认为,我们从出生到现在都一直在构建我们自己的思考和知识体系。 我们接收到的信息,都会通过总结,过滤,来补充到这个体系中。然后大脑再依据这个体系来指导我们对事,物的反应,即我们的行为。所以总结和过滤的方法就极为重要,对学习速度,效率都有着至关重要的作用。
总结,我们一定是对同一系列的信息进行总结提炼,既然是同一系列的信息,我们可以把它称之为同一领域。(对,我们最后又扯到了领域驱动),确实,小刀在学习领域驱动时,就是根据以前小刀对总结的方法论改变过来的,也就是,小刀是怎么总结的就怎么去进行领域研究的。
https://www.lixiang.red/articles/2019/07/25/1564025186602.html
如上文所说,有三大步: 1.提取关键词;2.深入业务场景;3.强化领域概念,划分上下界

提取关键词

我们接收到的信息总是杂乱无章的,如我们的会议,真正能做到条理性发言的很少. 大多数都是随性而发,想到什么就说什么, 我们要表达的可能就一个句,然后用十句话去解释这一句,好让别的小伙伴能听懂. 那提取关键词就是从别人的发言中,把他想要真正表达的一句话给提取出来.

深入业务场景

这里的业务场景是指我们讨论主题,如果自己本身对讨论主题不思考的话,那肯定是总结不出什么的,如同开会时,如果自己不提前准备下会议主旨等,那开会肯定是一脸懵逼. 我们要先自己对主题有深入的思考,在思考的同时,搭建自己的知识体系起来,有句话怎么说来着,啥事都有个一二三,对,再简单的事,也能拆出个一二三,分子能拆成原子,原子还能拆成电子呢. 总之是,通过自己对主题的思考,把事情的条理性简单的划分出来

强化领域概念,划分上下界

强化领域概念,就是吸引,转化别人的发言,慢慢补充到自己的知识体系中来,这里想强调转化一词,别人的发言使终是别人的,即使我们用笔抄了一遍,用录音笔录了下来,如果不转化的话,那使终是别人的,这里换成领域里面的场景就是,让开发人员,产品人员,领域专家的语言表达达成一致,在实践时,我们在用不同的语言描述同一件事,但是在讨论总结时, 我们把不同的语言提炼成同一种语言,大家都懂的一些词去表达. 这些词组在一起,就是自己的知识体系(领域语言)
划分上下界,在我们自己的知识体系中,简单来说,就是分层次的概念,人无完人,金无足赤,我们最开始在分出条理,划分层次时,肯定不好一次到位,那么我们就需要根据别人的发言,来完善这个层次,条理,哪些可以分在一起,哪些需要重新组成等等

最后说两句

微服务只是架构史上发展示的一个节点,不会是最后一个,如现在兴起的serverless, 谁知道serverless后面还会不会有呢, 所以我们一定要透过现象看本质,各个技术迭代中加重了什么,减轻了什么,封装了什么.
插入一点: 上面这一段,可以做为上面说的总结方法的一个体现点. 我们对技术架构演进做了一个层次划分: 1.加重了什么. 2,减轻了什么. 3,封装了什么. 以后我们在和别人讨论技术架构演进时,就可以从这三个方面出发, 然后不断加强,深化理解.
大家对微服务有什么见解,或者对总结方法有什么好的想法,欢迎随时和小刀交流: best396975802


标题:微服务|微服务总述|学习方法|总结的方法
作者:xiaodaojava
地址:https://www.lixiang.red/articles/2019/08/16/1565916942892.html

Responses