一个应用，需要有两种形态，一种单机，一种分布式？

[gzk329]

有什么案例可以参考吗？目前已经有一个版本了，想好好设计一下。
这个应用基于 Springboot 开发，想做一个类似 SPI 注解，有两个 Scope ，一个 single ，一个 distribute ，我看 dubbo 就有这种设计？刚看。一年不到经验，刚入手这个项目。

[Dmumuxi]

从打包方式和部署形态入手？单机就都打成一个 jar ，分布式就分模模块打 jar

[bugmakerxs]

我们目前也有类似需求。我的想法是每个服务都需要将 controller 、service 、api 分成不同 module ，代码分为 AController/AService/AApi BController/BService/BApi ，其中 AApi 和 BApi 根据配置判断是走反射调用本地方法还是 http 调用远程方法；
如果要作为分布式应用，A 服务打包形式为 AController+AService+BApi ； B 服务打包形式为 BController+BService+AApi ，走远程调用；
如果要作为单机应用，打包形式为 AController+AService+BService+AApi+BApi ，api 模块通过反射调用 AService 或者 BService 中的方法。

[pangdundun996]

没懂，单机 /分布式只是部署方式，跟代码有什么关系？

[pangdundun996]

@bugmakerxs 如果是这种要求的话直接分 module 打包就行，dubbo 是支持本地 jvm 调用的

[goinghugh]

你想要的应该是模块化以及合并部署的能力，蚂蚁的 sofa 有类似的能力； dubbo 能解决调用的问题，模块化估计要自己实现

[IvanLi127]

分布式的项目部署在同一个机子上不就是单机了？还是说单体？

[kytrun]

一个思路： https://github.com/smart-cloud/smart-cloud#%E5%9B%9B%E6%9C%8D%E5%8A%A1%E5%90%88%E5%B9%B6%E5%8E%9F%E7%90%86

[nothingistrue]

如果是单纯的多节点负载均衡，那单机跟分布式没多大区别，事实上这里压根也就不是分布式。

如果是一个服务，既能单独提供完整单机服务，又能作为服务节点插入到另一个微服务集群中。那么用 Spring Cloud （原生那个，不要用混乱的 Spring Cloud Alibaba ）就够了。只要你不搞配置中心，那么，如果禁用了服务注册，或者说连接不上注册中心，那每个服务都是独立的完整服务。如果启用了服务注册，同时又在防火墙上禁用了单个服务的直接访问，那么就没有独立服务，只有微服务集群了。

不要看 Dubbo ，这货本质上是 Java 远程调用框架，不是分布式协作框架。

[xiang0818]

1 年经验，你先理解下什么是分布式吧。

[Gonlandooo]

这个很简单，假设你的项目 Project 有 A 、B 两个模块、你需要他们既可以单机部署，也可以微服务部署
1 、你需要在 Project 项目下分三个包，分别是 A 、B 、Single ，

2 、A 、B 是你的微服务包每个包需要包含 core 、starter 两个包，这两个包的依赖关系是 starter 依赖 core 包
Single 包是你的单体包，只包含一个 starter ，依赖 A 和 B 的 core 包

正常情况下 starter 包里只有一一个启动类，所有业务逻辑在 core 包里正常写。

当你需要 A 服务调用 B 服务时，你就新增一个 service ，这个 service 有两个实现：
单体实现写在 Single 包的 starter 里面，直接注入 B 的 core 包里的对应类进行调用
微服务实现写在 A 的 starter 包里面，调用 B 的 feign