大家好，今天来为大家分享微服务各个应用之间如何数据同步的一些知识点，和微服务不建议使用多数据源的问题解析，大家要是都明白，那么可以忽略，如果不太清楚的话可以看看本篇文章，相信很大概率可以解决您的问题，接下来我们就一起来看看吧！
本文目录
哪种IT应用架构只需要一套软件和数据
在大多数情况下，IT应用架构都涉及到多个软件组件和数据存储。然而，如果您希望只使用一套软件和数据来构建应用架构，可以考虑以下两种情况：
1.单体应用架构（MonolithicArchitecture）：单体应用架构是一种传统的应用架构模式，其中所有的软件组件被打包在一个单一的应用程序中。这种架构方式将应用程序的各个功能模块以单个、整体的形式进行开发、部署和运行，所有的数据也存储在同一个数据库中。尽管单体应用架构具有简单和集中管理的优势，但它可能存在可扩展性和维护性方面的挑战。
2.低代码/无代码平台（Low-Code/No-CodePlatforms）：低代码或无代码平台是一种提供可视化开发工具和预构建组件的应用开发平台。通过这些平台，您可以使用少量或无需编写代码的方式来构建应用程序。这些平台通常提供了一套集成的开发环境和数据管理功能，以便在同一个平台上管理应用程序的开发和数据存储。
微服务各个应用之间如何数据同步
1.使用消息队列：使用异步消息队列系统，如ActiveMQ，RabbitMQ等，消息队列系统能为微服务中的多个应用提供集中式的消息存储和处理服务，这样就能实现应用间的数据同步。
2.使用API网关：API网关可以作为不同应用之间的网关，来实现对其他应用的调用和数据同步，通过API网关把多个服务集中起来，既使得应用之间的交互简单，也使得应用数据的同步变得更容易实现。
3.使用数据中心：将数据中心作为连接各微服务的中心，通过数据中心实现数据的存储，共享和同步。此外，数据中心可以通过各种技术来支持数据的安全和性能管理，从而实现数据同步。
SOA和微服务架构的区别
1.
架构划分不同
SOA强调按水平架构划分为:前、后端、数据库、测试等;
微服务强调按垂直架构划分,按业务能力划分,每个服务完成一种特定的功能,服务即产品。
2.
技术平台选择不同
SOA应用倾向于使用统一的技术平台来解决所有问题;
微服务如何限制接口调用次数
这种限制接口调用次数的方式，我们通常称之为限流，那么为什么要做限流呢，一般有两种原因：
1.首先是防止服务提供方被大量的请求击垮
我们开发一个项目，最理想的状况是有多少请求，都可以正常地响应，但是在现在的互联网环境，我们很难评估用户的增长，很难评估访问量有多少，甚至有些时候会遇到恶意攻击；那么相比于项目被流量击垮，【限制流量，只满足部分访问的正常响应】要好一些。
简单说就是：满足所有请求>满足部分请求>项目被击垮，所有请求无法响应。
2.计费
现在很多平台对外开发的接口，并不全是免费的，比如普通会员每天只能调用1000次接口，高级会员每天可以调用10万次接口，或者按照调用量计费。
那么如何限制服务接口的调用次数呢？
使用限流算法通常我们可以通过限流算法达到限制接口调用次数，比如计数器法、滑动窗口法、漏桶算法、令牌桶算法，这里我们就用令牌桶算法举例。
令牌桶算法，我们可以看做有一个桶，桶里面有N个令牌，并且系统会以一个恒定的速度往桶里投放令牌，每次处理之前先要获取令牌，如果获取不到的话，就拒绝服务；在这里我们使用Google出品的Guava工具库，里面提供了一个开箱即用的令牌桶RateLimiter。
如图，我们编写了一个简单的接口，省略了业务逻辑，只返回一个字符串；我们设置RateLimiter.create(2)，表示每秒不超过2个任务被提交。
让我们用接口工具模拟一下并发调用：
他强任他强，我自巍然不动。因为我们使用了限流算法，每秒只处理2个请求，所以从日志中我们可以看到这样的效果：每秒只有两条日志。
分布式架构下的限流因为使用开源的组件，限流的实现看起来非常简单，但是这里也有一个比较大的问题，就是实例中是一个应用包，但在实际的项目中，我们通常会是用集群部署的方式，将我们的应用部署在多台机器上，那么这时候该如何限流呢？
每台服务器上的应用自己控制自己的响应数量？比如每天只能调100次，那部署10台的话，总量就变成了1000次了；
反推？因为每天总量只能调100次，部署10台，那就是每台每天只能调10次？这是个很差的办法，先不说流量一定可以平均分配到每台机器上，如果有一台机器挂掉了，是不是今天只能支持调用90次了？
通常的解决方案，可以把令牌桶中的令牌，不要放在本地，而是放在一个公共的地方，比如Redis中，每次请求过来，就计算是否超过限制的总量，如果未超过，则正常处理，如果已超过，则返回错误信息。
具体做法是，用Redis中的key-100作为令牌桶，其中100表示一分钟可以调用100次，每次处理前对value进行减1，返回的值大于0表示可以处理；每分钟将value设置回100；或计数累加，开始是0，不断累加，最后超过单位时间的总量限制；
不过这个方法要有一个定时任务，去设置令牌的数量，另外这种方法是不能应对突发流量的，比如前59秒一次请求也没有，第60秒来了100次，第61秒进入了一个新的周期，又来了100次请求，这样实际上是在两秒内处理了200次请求。
另外一种方案是使用Redis中的有序队列SortedSet，存储近100次的调用时间，每次有新请求的时候，对比队列中第一个元素的时间和当前时间，如果相差超过1分钟，表示还没有超过流量限制，进行处理，并将第一个元素压出队列，将新的请求时间压入队列。
我将持续分享Java开发、架构设计、程序员职业发展等方面的见解，希望能得到你的关注。关于本次微服务各个应用之间如何数据同步和微服务不建议使用多数据源的问题分享到这里就结束了，如果解决了您的问题，我们非常高兴。
