备战2022春招或暑期实习，祝大家每天进步亿点点！
本专栏将会两个月持续不断输出Spring Cloud Netflix/Alibaba 全系列知识点，力求达到大厂面试和企业级开发水准
关于《Redis入门到精通》、 《并发编程》、《Java小知识100例》等知识点可以参考我的往期博客：《Redis从入门到精通》系列 《并发编程》系列 《Java小知识100例》
相信自己，越活越坚强，活着就该逢山开路，遇水架桥！生活，你给我压力，我还你奇迹！
1、简介
微服务是一个互联网应用行业大家都不陌生的话题，无论你是摸爬滚打多年的职场老兵，还是出入社会的职场萌新，只要谈及到微服务这三个字，我相信你都能侃侃而谈，指不定你还有自己独特的见解。（🌲🌲在这里小捌欢迎大家在评论区或私信给我留言，我们一起探讨微服务的奥秘！！！🌲🌲）
微服务它是怎么来的（小捌这里在网上搜刮了一些资料）
2011年5月，微服务这个概念最早在意大利威尼斯的一个软件架构会议上被提出，此时微服务用于描述一些作为通用架构风格的设计原则。
2012年3月，ThougthWorks（思特沃克）公司的首席咨询师James Lewis在波兰克拉科夫举行的“第33届学术会议”上，做了题为“Microservices-Java,the Unix Way”的演讲，这次演讲他主要谈及：康威定律、DDD、服务的单一职责原则等微服务特性
随后同年，Fred George在Agile India技术分享大会上正式提出微服务架构，他通过讲解自己所在团队如果拆分服务，如何通过MQ（Kafka）进行应用间的解耦，自此微服务架构就真正诞生了。
微服务虽然在现在非常火，但是微服务并不是一切架构建设的“银弹”！是否应该选择微服架构作为新项目建设的技术架构，或者原本的老项目是否应该迭代为微服务架构，这些问题都需要结合实际的业务场景、功能需求、技术和运维团队实力、基础设施是否足够扎实等多方面综合考虑之后再做定夺。总之强扭的瓜不甜，生搬硬套肯定是不香的！
微服务架构已经发展了近十余年了，现在国际上关于微服务架构的解决方案不胜其数；而我们常见的解决方案有Spring Cloud Netflix和Spring Cloud Alibaba，虽然微服务架构到现在为止发展的十分成熟，但是它也并不是一蹴而就的，其中的知识点也非常多！🔫小捌将会在2021年最后两个月死磕Spring Cloud，以下两张图小捌会从应用、源码等方面深入研究，需要的小伙伴可以关注小捌，我们一起进步呀！！！🔫
Spring Cloud Netflix 相关组件
2、架构演进
微服务架构本身发展了近十年，而之所以诞生了微服务就需要了解一下服务架构演进的历史啦！服务架构大致经历了单体架构、垂直架构、SOA架构和微服务架构的演进历程，接下来我们一起看看这些架构！
2.1 单体架构
单体架构指的是，将整个系统所有的功能都打包成一个jar或war包、并且运行在一个进程中。相信这种架构大家都非常熟悉，小捌是18年开始学Java每天撸的就是单体架构应用，尽管那个时候微服务在国内已经很火了，但是我相信初学者都是这么过来的啦！
单体架构虽然开发迅速，但是它存在很多不足之处，这些不足之处我相信经历过的都懂（😖😖我相信很多小伙伴去到公司后，如果上来就让你熟悉一个几十万行代码的单体架构应用，且不说业务多复杂，代码逻辑就能导致三高发作了，多么痛的领悟！！！）。
单体架构不足之处：
代码耦合严重。修改代码时牵一发而动全身，经常出现改一个bug导致更多bug的情况。在当下效率至上的工作氛围下，单体架构是严重影响开发效率的！
部署速度慢、对系统影响大。单体架构的每次发版部署都需要一切重来，整个服务都会不可用，相当于JVM中常说的STO(stop the world)；而且过大的war包在部署时编译、启动都会很缓慢！
业务扩展困难。单体架构代码耦合、业务也容易耦合，这会导致新增需求时根本无法迅速扩展。
扩容苦难。当单体架构服务性能出现问题时，需要进行服务水平扩容，单体架构在这种情况下显得很无力，只能将整个应用都进行扩容，但是往往应用中只有一小部分性能出现问题。
2.2 垂直架构
垂直架构在一定程度上减少了单体架构的代码、业务耦合度，提升了应用程序的伸缩性。垂直架构采取分层的思想，将一个应用程序从结构上拆分成多个维度，最常见的垂直架构就是MVC分层结构的架构模式。垂直架构虽然带来了一定的好处，但是它并未解决单体架构的大部分（几乎所有）问题。
2.3 SOA架构
SOA（Service-Oriented Architecture）面向服务架构，它的核心思想就是服务化，服务在SOA架构中，是基本单元。SOA架构通过将系统服务化，通过约定接口进行服务调用、达到资源共享的目的。
SOA架构主要解决了以下问题：
打破数据孤岛问题。以前的单体架构都是烟囱，系统之间完全没有任何信息交互，这导致了企业内部各个业务系统之间形成了非常严重的数据孤岛问题。基于SOA架构系统服务化之后，通过中立性接口进行服务之间调用，能够达到共享资源、交互数据。数据就是金钱，数据积淀对一个企业的发展至关重要！
应用解耦。服务化使得系统的进行了业务层面的拆分，原本一个笨重的大系统，根据业务功能拆分为不同的服务单元，这样在无形中将应用进行了解耦。
服务重用。在单体架构中，我们只能复用代码，无法复用某一个系统（服务）。经过SOA架构改造后的系统，只要设计的足够好，共享业务是完全可以实现的。比如电商项目中的用户服务、库存服务、商品服务都可以实现一次开发多系统重用。
SOA架构的发展，推动了RPC技术和MQ技术的飞速发展，这也为后来的微服务之间的通信奠定了基础！所以小捌认为微服务架构和SOA架构难舍难分，且微服务架构站在了SOA架构这个巨人的肩膀上。
2.4 微服务架构
微服务架构与SOA架构一样，服务是其架构设计中的基本单元。两者的区别在于侧重点不一样：
微服务侧重服务细粒度的拆分
SOA侧重服务化后服务的可复用性
那是不是说微服务其实就是升级版的SOA呢？小捌认为也不完全是，SOA中最常见的架构部分就是ESB（Enterprise Service Bus），ESB注重与服务交互和服务集成。微服务最关注的是服务的自治，微服务让整个架构体系更加智能、简单、方便、可靠；比如微服务推动了DevOps的快速发展、推动了云原生的快速发展等等。（不知道小捌这种理解对不对，大家一起讨论哈！！！）
现如今的微服务，不在是简简单单的将服务拆分，而是关注与服务之间的通信、服务隔离、功能降级、服务扩展、可伸缩性、敏捷开发、快速部署、高可用、高性能、分布式等等。因此这些技术名词带来了非常庞大的技术生态，加上技术本身更新就非常的迅速，对程序员来说确实是一个不小的挑战。但是别怕，小捌和大家一起学习，一起进步！！！关注我，后续两个月持续输出Spring Cloud生态相关知识。
“我们遇到什么困难，也不要怕，微笑着面对它。消除恐惧的最好办法就是面对恐惧，坚持，才是胜利；加油，奥利给！”
