前言
1.为什么写这篇文章？
一是为了巩固自己的知识，毕竟好记性不如烂笔头，写一遍的同时也能加深自己的印象；二是希望自己的分享能给别人带来收获或者帮助；三是希望可以得到大神的批评以改正。
2.什么是为微服务架构？
按我个人的理解，微服务架构即是将一个大的应用程序按一定规则拆分成若干子应用程序（子服务）的框架，且每个子服务互不影响，一般来说，每个子服务会对应一个相应数据库。
3.微服务架构（springCloud）的优点？
①高可用性：传统的项目，诸如ssh，ssm或是springboot，在任何一处出现出现bug，如内存泄漏，都有可能导致整个项目的崩溃。而springCloud因为将各个服务进行了隔离，一个服务挂掉时不会影响其他服务的运行，这就保证了整个项目的高可用性。
②高并发/负载均衡：springcloud一般会搭配Nginx做反向代理，反向代理是把将来自客户端的连接请求以反向代理的方式动态地转发给内部网络上的多台服务器进行处理，从而达到负载均衡的目的；第二点，springcloud中有一个非常重要的组件——ribbon，ribbon有自己的负载均衡策略，如轮询、随机、哈希等，服务与服务之间通过feign来进行通信，而feign中 默认集成了ribbon。
③很多其他我没有想到的的优点，欢迎大家评论区指出
正文
springcloud组成
springcloud一般由以下几个组件组成
Eureka：注册中心，所有服务均注册进eureka，只有注册之后才能被其他服务发现
Gateway：网关，该部分是由一堆过滤器组成，主要功能是路由转发和过滤，前台请求如api/user/****转发进user服务，api/order/****转发进order服务
Authentication(auth)：鉴权中心，主要提供验证用户登录以及各个服务之间的通信权限的功能
Feign：服务于服务之间的调用组件
还有一些其他的比如集中配置中心、链路追踪等暂时没有使用到，不敢擅做讲解
我眼中的微服务架构(springcloud)
微服务架构.png
在我眼中，一个微服务架构大体就是长这个样子的，总共分为了7层，其中1-5曾都是需要我们开发人员去进行关注的，至于6和7层，交由OpenShift和各大云服务平台就能很好的解决，不需要开发人员太多关心。
简单讲解一下这个图，在前端技术上，目前个人比较倾向于vue.js+element-ui的搭配方式，vue相较于react和angular，上手比较简单，且学习成本低，目前用户也越来越多；而element-ui与vue完美契合，官方文档简洁明了，是目前较多pc网站的不二之选。
Nginx在这里的作用是做第一步的负载均衡，一般大型网站都会做集群化部署，此时Nginx负责将api转发进相应的网关。
api进入网关层后，会进行token验证，这里的token是指用户信息的token，若api没有携带token，网关会将请求拦截出去，若携带了token，则判断api是要请求哪个服务，进行相应的转发，比如我们的请求是"api/user/userController/selectUser"，那么网关将会把api转发进user服务，如果请求是"api/order/orderController/selectOrder"，那么网关会将api转发进order服务。
api进入业务层后进行业务处理，若需要跨服务调用接口，则交由feign去做这个工作，调用方式非常简单，只需要创建一个接口并使用"@FeignClient"注解，比如user服务调用order服务中的selectOrderNameById接口：
@FeignClient(value = "order")
public interface OrderService {
@RequestMapping(value = "/selectOrderNameById",method = RequestMethod.GET)
String selectOrderNameById(@RequestParam(value = "id") String id);
}
服务之间具体怎样相互调用的，在图中已经进行了描述，需要注意的是，此时的token是指业务服务之间的token，与用户信息的token无关，不要混为一谈。
支撑服务中的内容就比较多了，集中配置中心和日志聚合因业务复杂度不高，暂时还没有用到，像工作流服务和xxl-job(任务调度中心)根据自己的业务进行取舍，不是必须的。简单说一下Eureka的心跳检测机制：服务在启动后，会周期性的（默认30秒）向Eureka发送心跳，以证明当前服务是可用状态。Eureka在一定的时间（默认90秒）未收到客户端的心跳，则认为该服务宕机，注销该实例，在服务注册中心将该服务置为DOWN状态。
（感兴趣的话推荐大家看一下MyCat，分布式数据库中间件，开源的，目前我还在学习阶段 #手动狗头）
至于平台服务(PASS)和基础设施(IASS)，前面说到过，交由现在的各大平台去做就行，省时省力
结语
写到这里基本就写完了，本来其实想写很多的，但是很多细节的东西理解的不够，写出来也容易造成误导，就不敢写太多。
开始写这篇帖子的时间大约是在19年6月份左右，构思了很多，但是开始写的时候发现很多地方有“断层”，写不下去，之后沉淀了一段时间，整理了上面那个架构图，整理出来架构图之后又因为加班等原因，一直没有继续写，直到最近有时间了，才上来把这篇帖子写完。
到我写完这篇帖子的时候，我已经有将近一年时间没有做后端开发了，因为公司业务原因，最近一年一直在做vue开发，后端都快忘干净了，因此文中可能有许多不正确的地方，欢迎大家的批评指出，谢谢！
(转载请注明出处)
网友评论