CSDN|42 张图带你揭秘后端技术都要学啥？( 六 )

微服务技术的引进一定是想解决某个痛点。我不希望在一个系统中，一小点改动就影响到全局，希望各个功能模块拆分清晰，不管是测试还是运维都能节省更多的时间。那么单体的架构出现了哪些问题？

代码分支管理困难

各个部门分别完成各自的任务，但是最后需要 merge 在一起成为整个系统， merge过程经历的人都知道，问题是真XX多。所以不再是996

新增功能麻烦

随着项目的效益越来越好，用户的需求也更多，招聘的人可能更多，对于新手来说上来是一脸懵逼的，老员工忙的要死，新员工成为了摸鱼专家

耗尽连接

用户的增多，每个应用都得和数据库连接，给数据库的连接造成太大的压力甚至耗尽连接微服务“微"-------微微一笑很倾城，微笑，微小。顾名思义，讲一个大的系统，拆分为一个个小的服务，分别对各个小服务进行管理。这样说感觉太不专业了，专业点

大应用拆分为小模块
小模块不属于集群中
通过远程调用的方式依赖各个独立的模块完成业务的处理

这些小的模块就叫做------微服务，整体也就是所谓的微服务架构。既然拆分成了小服务，这么多小服务怎么协调成为一个问题，甚至都不知道怎么掉这个服务，所以在微服务的整体架构中出现了注册中心，谁需要调用使用提供的接口即可。如下图所示：

本文插图
注册中心从上图我们能知道主要是三个概念：

服务提供者

微服务的具体提供者，其他微服务通过接口调用即可

服务消费者

对应于服务提供者，按照提供者接口编程即可。这么轻松的嘛，当然很多细节。举个例子，注明的dubbo服务框架，服务接口通过Dubbo框架代理机制访问Dubbo客户端，客户端通过服务接口声明去注册中心查看有哪些服务器，并将这服务器列表给客户端。客户端然后根据负载均衡策略选择其中一个服务器，通过远程调用的方式发送服务调用。那么使用微服务需要注重哪几点？

本文插图
选择中的注意事项不要拿工具硬上需求，结合业务也许会更佳！
高可用高可用，意味着一台机器挂了没事，其他机器可以照常工作，用户体验一样倍棒，用户压根就不知道，卧槽，你居然升级了系统，我居然一点感受都没有。那么高可用总有个标准吧，是百分之80就行还是90？一个系统突然不能访问的原因很多：

硬件故障
数据库宕机
磁盘孙欢
bug
光缆断了

可用性指标通过多少个9来衡量，比如大宝系统可用性为4个9 ，意味着是99.99% ，说明它的服务保证运行时间只有0.01不可用。高可用涉及到技术成本和设备成本，不是说高可用值越高越好，而是根据具体工具具体场景而定，这里分享一些高可用策略。冗余备份任何一个服务都有备份，就反复我们都会对我们笔记本电脑相关文件进行备份一样，以防万一。即使一台服务器挂了，可以很快的切换以致于让用户不会觉得"这系统怎么这么渣" 。负载均衡使用多台服务器分担一台服务器的压力，满足高并发的请求。怎么实现的呢，应用程序会有一个心跳检测/健康检查机制，如果发现不妥切换即可。上面提到的数据库主主复制也是高可用的方案之一，技术思想果然是相通的

本文插图
负载均衡限流降级我们的目标不是没有蛀牙，而是希望整个系统不要挂掉。限流是对部分请求进行丢弃处理，保证大部分的用户可以正常的请求完成任务。降级：可以屏蔽部分当前看来不是很有用的任务。比如电商系统做秒杀活动的过程中，确认收货功能给予的压力挺大，暂时看来并不是核心任务，而且系统到期也会自动确认收货，所以暂时关闭，将系统的资源留给准备下单，放购物车的太太们异地多活：有时候我在想要是地震，火灾等自然灾害发生的时候，很多系统的数据怎么办啊。想多了撒，大些的系统多会在各个地方部署数据中心，采用异地多活的多机房策略。用户可以访问任何数据中心，那问题来了，用户的请求是如何到达不同的机房去的？