❶ spring-cloud在windows和在linux上部署的不同微服务消耗内存不一样
使用Spring Cloud构建实际的微服务架构。
基本概念:
使用Docker进行集成测试
混合持久化
微服务架构
服务发现
API网关
Docker
使用Docker对每一个服务进行构建和部署。使用Docker Compose在一个开发机上进行端到端的集成测试。
混合持久化
混合持久化其实就是说使用多种数据库来存储。不同的微服务实例都会使用它们自己的数据库，并通过REST服务或者消息总线来通信，举个例子，你可以使用基于以下数据库来构建微服务：
Neo4j(图形化)
MongoDB(文档化)
Mysql(关联)
微服务架构
这个例子演示了如何使用微服务创建一个新的应用。由于在项目中的每一个微服务只有一个单一的父项目。开发者为此得到的收益是可以在本机上运行和开发每一个微服务。添加一个新的微服务非常简单，当发现微服务时将会自动发现运行时的集群环境上。
❷ 微服务系统的数据库从mysql换成oracle,需要配置什么
首先检查你那些涉及到数据库的配置项在oracle下是否支持，其次检查你的服务里面有没有拼接的sql，语法是否兼容，然后检查数据库连接是否正确，基本就这些吧
❸ 微服务开发中的数据架构应该怎样设计
前言
微服务是当前非常流行的技术框架，通过服务的小型化、原子化以及分布式架构的弹性伸缩和高可用性，可以实现业务之间的松耦合、业务的灵活调整组合以及系统的高可用性。为业务创新和业务持续提供了一个良好的基础平台。本文分享在这种技术架构下的数据架构的设计思想以及设计要点，本文包括下面若干内容。
微服务技术框架中的多层数据架构设计
数据架构设计中的要点
要点1：数据易用性
要点2：主、副数据及数据解耦
要点3：分库分表
要点4：多源数据适配
要点5：多源数据缓存
要点6：数据集市
为了容易理解，本文用一个简化的销售模型来阐述，如下图。图1显示了客户、卖家、商品、定价、订单的关系（这里省略支付、物流等其他元素）。
图1 销售模型
在这个销售模型中，卖家提供商品、制定价格，客户选择产品购买、形成销售订单。根据微服务的理念设计，可以划分为客户服务、卖家服务、商品服务、定价服务、订单服务，以及公共服务（比如认证、权限、通知等），如图2所示。
图9 数据缓存
要点6：数据集市
数据集市是一个很大的话题。当现有的数据不能简单地通过几个表数据关联以及简单加工后就可以供业务使用的时候，就需要考虑构建数据集市。数据集市以数据运用的观点来分析加工数据，通过多源数据的导入、清洗、加工、视图做成等一系列的数据操作后，为业务提供可用的、稳定的数据源。例如，对销售分析中、什么样的客户喜欢什么样的商品、价格对销售金额的影响、销售金额跟地区日期的关联关系等多维度分析，就要用数据集市的概念，如图10所示。
图10 数据集市
数据承载着信息，好的数据架构设计会使业务系统变得更加流畅、更加容易理解和维护。本文只是总结一些在实际工程中的体会，供大家分享。如果有不足之处、也请大家补充、赐教。
（此文转载至GitChat技术杂谈）
❹ 微服务如何在不同数据库关联查询数据
在程序里处理，分别连接不同的数据库，依次获取你需要的数据。
祝好运，望采纳。
❺ 微服务架构数据库如何拆分
根据康威定律，团队的交流机制应该与架构设计机制相对应。因此，在微服务架构下，职能团队的划分方法是我们首先要考虑的一个核心要素。
❻ 数据库，如何保障微服务架构下的数据一致
包含三个要素：Consistency（一致性）、Availability（可用性）、Partition tolerance（分区容错性），并且三者不可得兼。
❼ SOA和微服务架构的区别
SOA与微服务架构，在架构划分、技术平台选择等方面，均存在一定的区别。
一、架构划分不同
1、SOA强调按水平架构划分为：前、后端、数据库、测试等；
2、微服务强调按垂直架构划分，按业务能力划分，每个服务完成一种特定的功能，服务即产品。
二、技术平台选择不同
1、SOA应用倾向于使用统一的技术平台来解决所有问题；
2、微服务可以针对不同业务特征选择不同技术平台，去中心统一化，发挥各种技术平台的特长。
三、系统间边界处理机制不同
1、SOA架构强调的是异构系统之间的通信和解耦合；（一种粗粒度、松耦合的服务架构）；
2、微服务架构强调的是系统按业务边界做细粒度的拆分和部署。
四、主要目标不同
1、SOA架构，主要目标是确保应用能够交互操作；
2、微服务架构，主要目标是实现新功能、并可以快速拓展开发团队。
参考资料
网络-SOA
网络-微服务架构
❽ SpringCloud项目，每个微服务配置一个数据源好还是微服务里配置多个数据源好
我们这边是所有服务统一使用同一数据源，数据库连接信息配置到环境变量之中，所有微服务统一读取这组环境变量。
你要是设置成多数据源，未来系统故障时查找数据方面的问题多麻烦啊。
对于业务需要，真的是有比如两个数据源的，假设是主数据源A和辅数据源B，那么可以基于辅数据源B搭建一个微服务，暴露API，由主数据源服务在需要时调用辅数据源的服务的API就好。
不过如果辅数据源可能只有一个最简单的查询，没有更多操作了，你在主数据源服务中直接配置多数据源也没问题。
我仔细想了一下，似乎还是各个数据源单独起一个自己的服务这样更有“分布式微服务”的样子呢。