很遗憾，微服务拆分没有标准，更多是经验，以下内容是从我写的书籍上复制的。我们从高内聚低耦合、业务模型、读写模式、演进式拆分、阶段性合并这些角度再来介绍服务拆分原则。1.高内聚、低耦合高内聚、低耦合是软件工程中的概念，在软件设计中通常用耦合度和内聚度作为衡量模块...

服务拆分我引入我写的书上的内容来答复 我们从高内聚低耦合、业务模型、读写模式、演进式拆分、阶段性合并这些角度再来介绍服务拆分原则。1.高内聚、低耦合高内聚、低耦合是软件工程中的概念，在软件设计中通常用耦合度和内聚度作为衡量模块独立程度的标准，这个标准在微服...

这是一个很好的问题，在微服务架构中比较容易出现。针对你这个疑问，可以先将项目划分为原子层（实现数据操作，和业务无关），聚合层（对面的端提供服务）。app端和web端由不同的聚合成提供服务，但是由同一个原子层提供数据支持，这样就解决各端依赖的数据不一致的问题。...

这个问题有点大，拆分成上万个服务的业务，不能单纯的使用现有开源微服务架构，而是需要基于目前微服务架构做扩展，做个性化定制。假设按5000个服务计算，每个服务平均按2个副本计算，那么就有10000个服务，服务和注册中心的心跳都会导致很大问题。...

单一服务内部功能高内聚低耦合也就是说每个服务只完成自己职责内的任务，对于不是自己职责的功能交给其它服务来完成。闭包原则（CCP）微服务的闭包原则就是当我们需要改变一个微服务的时候，所有依赖都在这个微服务的组件内，不需要修改其他微服务。服务自治、接口隔离原则尽量消...

1、基于微服务架构的业务应用系统，在系统内，各个微服务之间调用的流量，属于东西流量，通常是不做网络隔离策略。2、在系统外，是属于南北流量，可以在流量入口的负载均衡，防火墙，K8S集群的Ingress上评估做网络策略。...

微服务只是原有单体服务的一种重构，现在很多系统一开始就是微服务，分布式，有些系统如果需要做成微服务，便于容器部署的话就需要从头重构，重构的模块建议按照业务和功能划分，比如可以用现成的spring cloud的框架，在框架种子其实很多常用模块或者公用模块都是固定的，咱只需要增加其...

打包不同镜像，用helm chart 编排

首页我们要学会如何记录日志、日志到底要记录哪些内容、然后再谈如何快速定位日志。1、日志需要记录哪些内容方法名称、入参、出参（根据阶段来确定，初始阶段建议记录，方便排查问题），记录SQL语句、记录SQL执行时间、方法执行耗时，traceid2、对于异常需要打印异常堆栈3、引入trac...

轻量的，无状态的服务应该都适合，比如web服务，不适合有状态的服务，比如缓存服务，数据库服务等，主要还是要看自身的需求