07.尚硅谷_SpringCloud_微服务优缺点

好，同学们，那咱们继续了解了微服务和微服务架构，那么呢，我们呢，就来看看微服务的好处和缺点分别是什么，那么呢，结合我们之前做过的项目和讲到现在大致呢，从读论文到我给大家介绍的相关内容，大家呢，请思考一分钟，你觉得从单机版到分布式，再到我们的微服架构，大家觉得他们的优缺点有哪一些？我呢给大家呢思考一分钟，待会儿我们找两个同学过来提问一下，好，我先暂停一下录屏。好，非常好哈，感谢同学们的答复，那么呢，部分同学的回答呢，还是答到了点子上，那么下面呢，我们就来读这一个一个的对比，看看这个微幅好，好在哪，不足有哪一些？那么呢，请跟我走。那么呢，首先。

我们呢，来看一下它的优点是吧，那么呢。首先化转为零被开了。那么言下之意。每个服务足够内置，足够小，如同我们说过的，专业的人做专业的事儿，这样的话呢，不再是一大堆的耦合了，那么我呢，要改一段代码，或者完成一个空难，我可能就是这小块，我不用去全局了解，但是大家呢，现在都在有种感觉，做单机版的时候，有可能你要需要改其中的几行代码，你需要了解的是整个系统。很费劲，而现在呢，我们呢，让他足够的讲代码数就容易理解了啊，他不牵扯别的，大家都是各自独立的，我就只做一件事，那么呢，这样的话呢，让大家呢干嘛？约手上。方便一些，我关注聚焦于一个指定的业务功能或者是业务需求。第二点。我们有个好处是什么呢？开发简单吧，开发效率提高，一个服务就看创业的事事少，听力集中，那么呢，不如此类。

小团队。两到五个人，那么大家是作者给出的一种换算的概念，你不能说超过五个数字，不是为服了，哎，这不能这么说哈，从这可以说到的意思是团队小而美，小耳钉，那你想嘛，你作为一个项目经理，你管五个人能够做出一件漂亮的事，和你管50个人，他的管理成本是不是不一样啊？哎，再来。服务耦合说难听点也偶了吧，无论在开发阶段会都是独立的，我们在读论文的时候还记不记得说过分造吃饭这个以前的话是连坐，大家都在一块，一个人感冒了，可能全部的人都要遭殃，但是现在咱们大家都分开，各住各的小房间，不会给大家带来不必要的污染和传播，那么继续用不同的语言开发，当然了啊，最终接口调用这个呢，我们在前三的时候。

有指导老师给大家介介绍过一门基础数学web service啊，那么web它是不是也可以是跟语言无关的，那么最终我们往下看一级和第三方集成，这就不多说了，那么呢？最主要的。我呢喜欢于这个，大家看微服务业务逻辑的代码，不会和面和C和其他界面逐渐混合，哇，这个是我最爱的一个，那么呢，在安金的开发单号。我们呢有两种FR模式，那么这个呢，你们班的一半对一半各位同学的运气了，第一种呢是什么要前后抓分离，如果说你去的是这样的互联网公司，那也就是现在目前比较一同的，那么换句话说的话呢，干嘛我们阿法程序员。

相对而言。比较幸福，为什么呀，那么也就是说我们只需要管理后端A。前端的H5工程师。就按照约定，约定什么呢。Rest地址加输入参数。格式和什么？豹纹。约定二输出参数。对，后期的话，那位同学说的很对，那么换句话说的话呢，大家一定学过一种艺术，叫quiryquiry，是不是多了点post，这个时候我们就类似哈，这是一个rest地址啊，这是不是一个T入差。

然后这款是不是回调函数。那么呢，这样的话呢，就是说我们Java程序员不管前台界面的样式，你这卷的那些功能，那些咱做不了，那是咱们对面这个班H5前端妹子该干的事，我们只管后端的业务逻辑好不好用，技能高低，那么我们跟前端的开发工程师约定好调用的地址啊，约定好它输入的参数之后，我们呢，回传给他，只要他能够收到一个程串，那么前端该怎么解析就怎么解析，这样的话，我们后端工程师是不是只需要关一的关注的关系与后端的一个微服务而动前端的改变啊，因为对Java程序而言，我相信你们学一个技术，比方说SS啊这些东东的话是不have啊。

那么这些东西的话呢，相信同学们是不是学起来也非常痛苦啊，因为毕竟哈，页面好不好看，感现那些是炫的效果，不是我们Java开发工程师的想项，那么第二种呢，有可能呢，轻点哈，那么当然了，也没有什么倒不倒霉的哈，就是看你的工程的要求，他不管那么多，他没有前后端分离，如果说前后端分离，这样你就会特别的体会到杨哥所说的这句话，微负的优点，我们只关注业务逻辑代码，不会和前面CSS或其他界面组合，就给全台一个。Rest地址和一个结算串，那么第二种呢，就是现在俗成了什么全站工程师啊，那这个呢，你就从头做到尾H5啊，完可能再加后面一堆东西，比方说red SQ等等哈，那么做了这么一个端，但是呢。

他说大家学过javascript，但是呢和认认真真要把前端掌握好，还是要花点力气的，毕竟的话，我们上硅谷的H5学科，前端学科也是要学五个月吧，你在这学了。六个月小半年了，大这些东西30多种技术也够你喝一壶的了吧，那么所以说呢，如果是权杖工程师啊，那么你可能就辛苦一些，读了断的要懂，前端的呢也要懂，能理解，哎，如果说是这样的，你呢，就会体会到开发的微服务我不管，我就是传一个第三串透，传了以后手工后续我们做实战的时候，大家会看到这种代码的编法方式非常舒服。那么第二个干嘛呢？每个微服都有自己的存储能力，可以有自己的数据库，也可以有统计的数据库，那么是不就是我们所说的什么。可以灵活搭配。那么呢，连接。酷。

又可以连接独立的库啊。那么这样的话呢，是不是在数据上的独立性，数据上的共享性上面都有自己非常舒服的特点啊，哎。那么呢，这切切就是我们微服架构的优点，那么好比一个硬币，就像一个硬币有两面，有优点偏然有缺点，那么呢，你不能接受它最大的一面，你也不能讲受它最美的一面，哎，小而美，小耳钉，赤微夫的特点，那么缺点呢，人无完人嘛，那么所以说呢，我们也来看看。头疼的微服务架构上面的一个一个微服务，首先化整为零以后，以前是个。现在呢，可能是十，可能是100，那么服务和服务之间的调用和通信这个成本上来了，有没有可能。调不通，有没有可能会调用超时？第三，一个运维工程师压力贼大吧？以前你丢给我only one，你这个挎包我一往Linux上一扔，收到。

现在你可能扔给我是200个为服务。我需要去写脚本，统一的部署，我需要去监控一个一个的服务，到底200个微服务是123号微服务出问题了，是178号微服务调不通了，那么等等这些问题是不是也很头疼啊，而且更恐怖，更关键的是什么？只要是分布式架构干嘛？我们是不是一定会涉及到一个分布式的通信和事物的控制啊？那么呢，我们也来看看它的缺点呢？分布式系统的复杂性不用多说了。运维。多个系统的部署依赖，那比方说是你是独立了，但是假设你这个系统有20个维护构成。上一张桌子。有四个团或者三个团，就说打麻将缺一吧，那么你这个时候呢，不算其他好的一个，可能有时候调不通功能是不是不爽啊，那么还有服务的通信成本，调用高时数据的一致性等等，那么所以说微服务也不是完美的，它作为一种架构，目前呢平看呢蒸蒸日上，那么同学们呢，也就在后续工作中多体会，多总结太阳它的优点，避免它的缺点，OK，那么二我们呢，来了解了微服务的优点和缺点，那么同学们可能在面试的过程当中会问你啊，记住一二个。

维护架构的优缺点，谈谈你是怎么考虑选型的？那么在这请同学们有过一个参考和印象。