在谈到网关的时候，首先需要确认下目前微服务的业务线有几条，如果只有单一的业务线，其实有没有网关意义不大。其实网关可以理解为一个反向路由，它屏蔽内部细节，为调用者提供统一入口，接收所有调用者请求，通过路由机制转发到服务实例，同时网关也是“过滤器”集合，可以实现一系列与业...

超融合是比较偏底层的技术，微服务涉及开发统一规范，这是超融合做不到的，厂商也不具备这方面的支持能力，如果是基于VMware的超融合，网络融合是有的，有分布式网络技术，还有高级可选的NSX功能包，负载、防火墙、vxlan全都有。另外超融合本身依托虚拟化平台提供资源，像应对海量文件这种...

简单的可以引入skywalking、zipkin等链路跟踪工具，可以详细的查阅skywalking\zipkin详细文档也可以自己实现，由唯一的logid串联起来，同时能标记前后调用顺序，记录parentlogid，查询的时候通过logid就可以全部查出来，通过parentlogid按顺序展示。...

1、超融合架构非常合适微服务架构的部署。一台超融合节点不仅可以提供虚拟机资源，还可以同时提供存储资源，在部署微服务架构时，可以做到快速部署和按需扩容。单台超融合节点根据配置不同，可以提供几个到十几个虚拟机，还可以同时提供TB级别的存储资源，可以高效的利用单台服务器...

这个部署要按照企业的架构来定，无论部署在公有云或者私有云。但是要考虑以下几点：1.复杂度高的业务，尽量将网关部署在内网2.对接上下游供应商的系统一般都会通过外网发布，所以无需穿透网关从个人在制造业的经验来看，网关最好放置内网。...

可以尝试使用微服务管理平台，一般都包含服务治理及全面数据化运营等功能，应该能满足您的需求。服务治理：提供异构服务间的服务注册与发现/服务鉴权/服务路由/服务限流/分布式事务/分布式配置/分布式消息等基础微服务治理能力。全面数据化运营:完整的资源、应用、服务数据跟...

之所以采用微服务架构，无非两种场景，一是系统解耦，二是数据逻辑的拆分。针对共享底层架构的问题其实可以从服务的拆分来解释。 微服务化将服务进行拆分，通过网络服务进行通信，在这种情况下，会出现两个要解决的问题，一是微服务架构自身组件的性能损耗，还有个就是问题中所提到的底...

某大神总结的单一职责、高内聚低耦合服务粒度适中考虑团队结构以业务模型切入演进式拆分避免环形依赖与双向依赖

如果当前业务系统能支撑好多年的业务发展，建议还是求稳吧。需要看清楚当期业务系统是否为敏态应用，是否需要经常变更版本。当期是否因为部分业务变更影响整个业务链条的正常交易。是否需要对部分服务进行动态扩展，做灰度发布等等。业务系统如何拆分，拆分粒度多大这个问题很难...

松耦合的架构理念，是使得每一层处理自己的事物，而不和其他层耦合，前后端分离，应用层和数据层分离，网络层与逻辑分发层分离，而层与层之间，用api接口对接。微服务的高可用，由kubenetes的容器副本来保证；数据可用性，当然最好是有数据层的副本来保证；数据的强一致性，在分布式存储中很难保...