小机灵鬼|42 张图带你揭秘后端技术都要学啥？( 七 ) 作者|L的存在来源|我是程序员小贱（ID

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

代码分支管理困难

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

新增功能麻烦

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

耗尽连接

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

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

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

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

服务提供者

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

服务消费者

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

选择中的注意事项
不要拿工具硬上需求，结合业务也许会更佳！

高可用高可用，意味着一台机器挂了没事，其他机器可以照常工作，用户体验一样倍棒，用户压根就不知道，卧槽，你居然升级了系统，我居然一点感受都没有。那么高可用总有个标准吧，是百分之80就行还是90？
一个系统突然不能访问的原因很多：

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

可用性指标
通过多少个9来衡量，比如大宝系统可用性为4个9 ，意味着是99.99% ，说明它的服务保证运行时间只有0.01不可用。
【小机灵鬼|42 张图带你揭秘后端技术都要学啥？】高可用涉及到技术成本和设备成本，不是说高可用值越高越好，而是根据具体工具具体场景而定，这里分享一些高可用策略。