传统单体大项目的缺点：
微服务：
微服务的优点：
微服务的缺点：
如果项目拆分过粗，那和单体应用差不多；如果拆分过细，则服务太多，管理难度大，服务调用开销大。
拆分的大原则：一个模块不依赖、或极少依赖其它模块，但需要给多个模块、客户端提供数据（一般2个或2个以上）。
springboot、springcloud可以联合部署。
比如查询订单信息，要访问订单的微服务，有时候需要访问多个微服务。
微服务部署在不同的服务器上，一般是无状态的，不保存用户的状态信息（比如是否已登录），需要找一个地方来保存用户的状态信息、检查用户权限。
一般要通过API Gateway来访问微服务。
API Gateway，其实就是一个代理，代理所有微服务，请求交给API Gateway，由API Gateway调用相应的微服务来处理。
API Gateway提供统一的接口，供前台调用，并保护用户状态、检查用户权限。
API Gateway只是一个称谓，有多种实现：可以是MVC框架，可以是node.js服务器，也可以是其它的。
服务之间有2种通信方式：
简单、一致性强，但容易出现调用问题、体验差，特别是调用层次多的时候（服务A调用服务B，服务B又要调用其它服务，类似于递归）。
同步调用有2种常见的实现技术：
要应用广泛、兼容多种情况，需要提供大量代码处理各种情况，移植性倒是上去了，性能就一般般（REST）；
对环境有要求，针对特定情况，移植性差一些，但性能杠杠的（RPC）。
在分布式系统中用得较多，Kafka就是一种异步消息技术。能降低服务之间的耦合，可以保证被调用者的性能。
同步消息：妈耶，一大堆服务调用我，我得加紧干，加大功率——强度大了可能直接拉闸，被搞垮；
异步消息：就像食堂的打饭大妈，不管排多长的队，依然不紧不慢地打饭，学生（其它服务的调用）都得排着队等着——想搞垮我，不存在的。
付出的代价：数据一致性差。
你倒是不紧不慢干着，人家都等着你，等了老半天，这期间数据可能被其它服务修改了、不一致了。
所以往往要写数据一致模块来保证数据的一致性。
通常要把一个服务拷贝一下，部署到多个服务器上，实现服务的分布式。
运行过程中，一些服务器可能会下线，负载大的时候也会增加节点（服务器），节点会变化，要发给哪个节点来处理？
找到、发现某个节点，使用这个节点来处理请求，所以叫做服务发现，常用的技术是zookeeper。
使用zookeeper来做服务的分布式管理：
服务提供者（各服务节点）把信息（本机地址、所提供的的服务）注册到zookeeper上，并实时更新信息。zookeeper根据这些注册信息、调用特定算法来计算，确定要调用哪个节点来处理请求，即发现一个服务。
那把zookeeper放到客户端、还是放到服务器端？
访问量上升，对某一服务的调用增加，如果不加处理，节点负载太大，会影响所有调用此服务的前台。
常用的处理方式：
原文：https://www.cnblogs.com/chy18883701161/p/12292352.html