微服务架构笔记

单体架构 ：页面和业务造成了耦合
需要拆开耦合度 由此产生出了前后端分离的架构（特点：用大量的JSP，而JSP是要在前端页面写的，这样的话就会造成一个问题，就是我前端都写好了，但是后端因为自己的需求需要改，很麻烦）

前后端分离架构：把一个服务器拆分成了
前端服务和后端服务。
1、向前端服务器发送页面请求。
2、返回页面
3、请求数据（前端和数据库连接，不需要逻辑判断用前端访问，比如IO）
4、由后端返回数据（后端和数据库连接，后端适合请求大量逻辑判断的数据）（现在只需要前后端约定后彼此需要的接口就行了）

集群模式架构：
多搞几个服务器来应对同时非常多的请求导致服务器挂掉
Proxy代理 多个代理 做个virtual ip
也是可以多个数据库

SOA架构：设计思想。 拆分拆分，拆成多个服务
耦合度降低，每一个小服务呢，都可以独立地进行工作。
所有的服务跑在ESB总线上，用来进行通信的。
解决服务热点地问题，因为服务有很多，但是
使用的频率肯定是不一样的，如果所有的服务都在单体里面
就很可能某个功能用的多导致整个系统崩溃。
而拆分成微服务以后，我们就可以针对某一个微服务去加强它的
服务器，这样的话就可以很好地应对热点问题了。

分布式架构：基于SOA演化而来，因为总线只有一个ESB，所以ESB
也还是有耦合的。通过网关去访问不同的服务。

微服务架构：把微服务组件化就是微服务机构了，不再是分布式架构。微服务架构和
分布式架构的主要区别是解决的压力问题。
微服务在分布式的基础上工程化组件化。然后可以针对每个
微服务去设计单独的数据库。
注册中心，每个微服务都需要去注册中心去注册，然后网关直接去
注册中心找就好了。
配置中心，解决配置文件下发的问题。
1、把各个服务抽象出来
2、多个数据仓库
3、微服务架构还有一个技术外的好处，它使整个系统的分工更加明确，责任更加清晰，每个人专心负责为其他人提供更好的服务。

微服务架构存在的缺点：
1、微服务架构整个应用分散成多个服务，定位故障点非常困难。
2、稳定性下降。服务数量变多导致其中一个服务出现故障的概率增大，并且一个服务故障可能导致整个系统挂掉。事实上，在大访问量的生产场景下，故障总是会出现的。
3、服务数量非常多，部署、管理的工作量很大。
4、开发方面：如何保证各个服务在持续开发的情况下仍然保持协同合作。
5、测试方面：服务拆分后，几乎所有功能都会涉及多个服务。原本单个程序的测试变为服务间调用的测试。测试变得更加复杂。