认识达内从这里开始

随着互联网的不断发展，程序员能够掌握的编程架构方式也在不断增加，而今天我们就通过案例分析来了解一下，常见的架构方式都有哪些。

ConfigService

提供配置的读取、推送等功能，服务对象是Apollo客户端(client)(最终目的就是把配置数据给到我们自己的微服务对象)

Admin Service

提供配置的修改、发布等功能，服务对象是Apollo Portal(管理界面)(简单理解成就是就是用来在配置中心管理界面来添加或者修改配置)

Client( 客户端)

Apollo提供的客户端程序，为应用提供配置获取、实时更新等功能。

域名访问 Meta Server 获取 Config Service 服务列表(IP+Port)，而后直接通过IP+Port访问服务，同时在Client侧会做负载均衡、错误重试

Portal

提供Web界面供用户管理配置。

Portal通过域名访问 Meta Server 获取 Admin Service 服务列表(IP+Port)，而后直接通过IP+Port访问服务，同时在Portal侧会做 负载均衡、错误重试

ConfigService 和 Client 的配合

从这里面可以看出我们自己的微服务不是直接和ConfigService打交道的,而是跟Client打交道，Client才是真正和ConfigService打交道来获取最新配置信息。

Admin Service 和 Portal

这里分类两个模块就很好理解了，因为管理界面的实现有自己的一套代码，而且管理界面操作的一些权限等信息,只会跟它自己有关系，对于微服务来讲，我只关心有没有配置

这条配置数据，而不会去关心在管理界面上什么用户能够添加配置信息。所以就有Portal对于了两个数据库，一个可以理解是它自己的，存放一些权限等信息，另一部分是和

配置有关的，所以通过 Admin Service 存放在 configDB 中。

Eureka

用于服务发现和注册Config/AdminService注册实例并定期报心跳。

为了简化部署，我们实际上会把Config Service、Eureka和Meta Server三个逻辑角色部署在同一个JVM进程中

官方也有解释为什么我们采用Eureka作为服务注册中心，而不是使用传统的zk、etcd呢?我大致总结了一下，有以下几方面的原因：

1)它提供了完整的Service Registry和Service Discovery实现

首先是提供了完整的实现，并且也经受住了Netflix自己的生产环境考验，相对使用起来会比较省心。

2)和Spring Cloud无缝集成

我们的项目本身就使用了Spring Cloud和Spring Boot，同时Spring Cloud还有一套非常完善的开源代码来整合Eureka，所以使用起来非常方便。另外，Eureka还支持在

我们应用自身的容器中启动，也就是说我们的应用启动完之后，既充当了Eureka的角色，同时也是服务的提供者。这样就极大的提高了服务的可用性。这一点是我们选择

Eureka而不是zk、etcd等的主要原因，为了提高配置中心的可用性和降低部署复杂度，我们需要尽可能地减少外部依赖。

【免责声明】：本内容转载于网络，转载目的在于传递信息。文章内容为作者个人意见，本平台对文中陈述、观点保持中立，不对所包含内容的准确性、可靠性与完整性提供形式地保证。请读者仅作参考。更多内容请在707945861群中学习了解。