如何简化Apollo的分布式部署流程？

[nobodyiam]

目前Apollo的一个痛点就是分布式部署有点太复杂了，虽然文档写得很细，不过乍看一下，细节非常多，如果用户没有耐心读完文档就开始部署的话，一般都会遇到这样那样的问题，影响体验。

所以还想请大家一起看看是否有啥办法能够简化Apollo的分布式部署流程，欢迎大家献计献策！

[oooooooz]

在目前的架构下，我们先来看单机布署一个环境要做哪些事情：

1，构建后发布。构建时选自己的 profile 加上 github 即可，原封不动官方配置。我们是自己拉代码下来自己构建的，所以有构建这一步。

2，修改配置。

• [A ] 修改配置文件：主要是日志路径（启动脚本中），数据库连接配置，http 端口，portal 的话还要配上注册中心地址。

为了方便修改，数据库配置我们写到 config/application-github.properteis，portal 的注册中心配到 config/apollo-env.properteis

• [ B] 修改数据库类：
  portaldb，修改 env 。
  configdb ，修改注册中心地址。

3，客户端
配置好 -Denv，注册中心地址配置到 apollo-env.properties

一个环境差不多要做就是这些。大家一般都是下载 release 版不用自己构建。配置部分的细节确实有点繁琐。对于 config 和 admin 服务，我的理解是配置文件类其实仅修改日志路径，和数据库配置即可，其他可以不改。portal 服务配一个好记的 http 访问端口。

---

好，以上说完单机单环境，现在看分布式或集群下的部署有没有优化空间。

分布式部署的话，portal 的话一般一个即可，但我觉得大部分公司还是要求生产和开发、测试分离的 ，

所以上面的步骤好像免不了都要走一遍：

1，构建看不同公司的需求，一般可以省略，直接发布应用即可。我们是因为增加了导出，所以合并做了构建，不知是否可以提个 PR ？

2，configdb，不同环境肯定是要新建立的。portaldb 要增加 env meta（这里假设 portal 不用重新部署）
3，admin 和 config 的应用要重新部署，然后和上面一样去修改应用配置，修改数据库配置
4，客户端。增加对应环境的注册中心地址。

总体下来感觉要优化的话可以从怎么优化 修改配置和数据库的细节入手。我觉得可以优化几点，总体的思路是配置集中化管理，可以配到数据库就配到数据库（这样方便扩展去界面管理）：

1，portal 应用，把 portal 连注册中心的地址配到 portaldb。这个时候对于 env 可以根据注册中心来增加，比如 dev.meta 就增加 dev，fat.meta 就增加 fat
2，数据库脚本还是要人工去执行，执行后修改配置
3，部分配置由 portal 去管理，比如 portaldb 增加一个表，专门用来维护 config 和 admin 的配置，portal 起来后，将配置推送到 config 和 admin 的配置路径。
4、portal 的相关配置还要老样去改

这样的化 config 和 admin 的配置就简化了。

以上抛砖引玉，欢迎讨论。顺便感谢宋大侠对社区的时刻关心，及时雨啊。感谢 @nobodyiam

[jiangshubian]

单机版: ./demo.sh start，portal一直无法执行到，是不是有bug? 把脚步portal启动部分独立开来就可以启动。
Quick Start:https://github.com/ctripcorp/apollo/wiki/Quick-Start中的安装包

[nobodyiam]

@jiangshubian 开个新的issue描述你的问题吧，估计是下载的时候少了conf文件？比如apollo-service.conf

[dypublic]

@nobodyiam 宋大神，想请教一下，Eureka和Meta server引入的目的是做config/admin server的服务发现吗？既然SLB（nginx）可以找到Meta server, 为什么不直接用域名绑SLB，SLB去LB config server，client 直接访问SLB->config server？这样就可以取消Eureka和Meta server的必要性了。

[nobodyiam]

client需要长连config service的（http long polling），如果走slb的话，对slb的压力太大。

[dypublic]

@nobodyiam 谢谢。那如果域名绑定多个SLB，即SLB集群，是不是就可以了呢？我们自己使用AWS环境，有NLB组件，单个NLB的性能就相当不错，可以认为是网络设备而不是SLB（nginx）。

[nobodyiam]

如果性能OK的话，倒也无所谓的，不过走LB也是有点浪费，因为内网其实完全可以直连的。

另外，直连规模也要考虑一下的，比如如果内网有6位数的机器，就会有6位数的长连，势必会增加不少LB的成本吧。。

另外一点就是走LB的话，需要在LB上调整超时时间的，目前apollo的http long polling最长会保持60秒。

[dypublic]

@nobodyiam 明白这个考量点了，谢谢 。对于6位数的时候，config server的节点经验上需要部署多少个呢？假设4核16G的机器。

[nobodyiam]

一台4核8G的config service服务10000以内的节点数是没问题的，留一些余量的话，建议一台服务6000 - 7000个节点吧

[nolan4954]

个人感觉，可以将config service和admin service集成在一起；即作为各个env下的client服务，又为总的管理后台portal服务

[hupuxiaojun]

我看到文档中写到如果需要使用单独的eureka注册中心的话，除了修改数据库中的url外，还需要修改源码将@EnableEurekaServer改成@EnableEurekaClient，然后重新打包编译源码。
感觉可以用@Profile的方式来控制是否要自启动eureka server，然后在启动时传入spring profile来控制，这样应该可以不用修改源代码，使用起来更友好一些,类似如下代码:

//@EnableEurekaServer
//@EnableEurekaClient
@EnableAspectJAutoProxy
@EnableAutoConfiguration // (exclude = EurekaClientConfigBean.class)
@Configuration
@EnableTransactionManagement
@PropertySource(value = {"classpath:configservice.properties"})
@ComponentScan(basePackageClasses = {ApolloCommonConfig.class,
    ApolloBizConfig.class,
    ConfigServiceApplication.class,
    ApolloMetaServiceConfig.class})
public class ConfigServiceApplication {

  public static void main(String[] args) throws Exception {
    SpringApplication.run(ConfigServiceApplication.class, args);
  }

  @Profile("EurekaServer")
  @Configuration
  @EnableEurekaServer
  public class EurekaServerConfig {


  }

  @Profile("EurekaClient")
  @Configuration
  @EnableEurekaClient
  public class EurekaClientConfig {


  }
}

打包的时候-Dapollo_profile=github,EurekaClient来激活配置

[lawrencewu]

部署文档可以以三台机器模拟的三个不同的环境为例,一步步写下如何部署的以便参考.与部署不相关的"注1" "注2" 等信息可以另写一篇参考文档, 分布式部署文档内容分支太多, 也繁琐, 不干净不流畅.

[nobodyiam]

@lawrencewu 很好的建议，后续分布式部署文档增加一个实际部署案例

[jimmy401]

linux suse 版本下会报错start-stop-daemon unrecognized option '--chuid'
建议支持多个linux发行版，
或者明确指出只支持centos系统。

[nobodyiam]

@jimmy401 这个貌似是spring boot脚本的问题，详见 #spring-projects/spring-boot#4772 和 Customizing the Start Script when It Is Written，可以试一下，如果OK的话，后续我们在文档中更新一下~