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

开头说两句

Java 基础 Demo 站: https://www.javastudy.cloud
Java 中高级开发博客: https://www.lixiang.red
Java 学习公众号: java 技术大本营

技术背景

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

什么是微服务

在了解什么是微服务之前，我们要先知道微服务的演进背景：单体架构->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