微服务导航

简介

最近都在弄微服务的东西，现在来记录下收获。我从一知半解到现在能从0搭建使用最大的感触有两点

1.微服务各大组件的版本很多，网上很多博客内容不一定适合你的版本，很多时候苦苦琢磨都是无用功

2.网上博客参差不齐，有些甚至错误的。更离谱的是，好的文章阅读量除非高出天际，不然就都很低，比那些复制粘贴，随便应付的都低（这个搜索推荐算法不知道基于什么的）

通过这段时间学习，我觉得最重要是从好的博客入手，先不要着急怎么组件怎么使用，而是先了解组件的作用，大概的原理，然后才是使用，这样搭建和尝试的过程中才能更好的定位问题，最后再次回到原理和一些实际问题的处理（不知道实际问题怎样的，直接搜那个组件的面试题往往效果最好）

接下来的内容，都以导航的形式展现给大家（毕竟优秀的轮子很多，直接看大佬写的不香嘛），再顺带提些自己的理解

微服务介绍

这篇博文主要介绍微服务的基本概念，让大家明白什么是微服务

在实际工作中会越来越觉得，用各种技术打造高性能，高并发，高可靠的系统无非就围绕两个字：省钱，为公司省钱，为自己省钱

这是很现实的事情，假如一个单机系统做的很差，服务器2核8G的不行就升级为4核，8核的16G，32G，64G的，性能不行，硬件来凑总能满足

别说几十万上百万的高并发，有多少公司能达到十几万，几万的。很多时候只要注意并发问题业务其实就能正常流转，性能意思下就够了，如果业务量升级就靠硬件去凑，因为硬件只要不是高标准还真的不是很贵（随着时代发展，硬件有着质的提升），就像考试30,40分努努力到60分一样，服务器从很低端的配置升级到低端配置也就小钱（比每个月多出几千上万招高级程序划算多了），而大部分公司业务量其实已经满足了（能挣到钱养活整个公司了）。

但还是要弄，因为随着业务量提升，需求扩展变更，如果代码不设计好，最终苦逼的还是程序员自己，重构是不可能重构的，所以只能在危楼上继续加盖。这期间时间的开销很大，收获的经验低价值。按照国内普遍35岁就程序员危机的行情来看，你还有多少时间去浪费，时间就是金钱啊。而高标准要求自己写代码的同时，也确实降低了线上出错的风险和最大效率发挥有限的资源（就是公司省钱了），因此自己努力就能达到双赢的局面

而微服务能有效解决应用高性能，高并发，高可靠3大问题，详情看链接内容，本文只是总结和提下经验

文章从单体应用开始，一步步因为需求的增加而逐步向微服务迈进（并不是微服务流行就用微服务），这篇文章引领我走入微服务的世界，让学习的方向更加明确

文中主要提到微服务的好处：

1.让每个服务功能边界清晰，理清依赖关系，从而减少冗余代码，方便扩展

2.让瓶颈的地方（如数据库）得到更好的解决（其实就是可扩展），其实如果不是程序设计的十分离谱，对于内存一般都是够用的，瓶颈几乎都围绕数据库展开，从而需要缓存（读多写少），需要MQ队列（异步执行，减少高峰期数据库压力）

3.增加系统稳定性，防止单点崩盘，同时减少测试和部署的复杂度（很关键的一点，经常会被忽略）

4.微服务会引来稳定性的问题（与3其实不冲突，只是不同角度看稳定性），可以从减少错误（事前监控、事后分析），降低影响（熔断、限流）两个方面入手

5.这里提一下服务降级。例如A服务访问B服务，B服务挂了，如果仅仅熔断，那么请求还是源源不断的进入到A服务中，只不过A服务快速返回失败（这和@FeignClient配置降级方法是一样的），服务降级另一方面则从请求的源头（如界面点击按钮没了，推荐界面没了）切断，这就需要前后端对一些功能有个开关，开关断了则前端停止请求。

6.最重要的还是结合实际项目，单机系统并非一无是处，服务划分才是关键点，合适自己的业务需求才是最重要的

至于微服务相关的CAP原则，Base理论，大家百度下就好，实际中还是要多接触微服务和分布式的系统才能有更深的体会，每项技术都有优缺点，只有最适合业务的，没有绝对的

小结

   本篇博客最主要是想让大家了解微服务的优缺点，很多时候学着学着就会忘记初心，不知道为什么要用这个技术（本人就经常犯迷糊哈哈哈），从而多个知识点串不起来就经常忘（好气啊，当时琢磨了这么久）。所以接下来的博客都以原理为主，具体使用其实还是比较次要的（很容易搜索出来），技术之间原理多多少少有互通点，也能让平日开发借鉴（咳咳，其实就是记不住这么多知识，只能挑重点了解，举一反三），希望能帮到大家啦~

本文作者：半天想不出昵称的斌