应用内：直接集成到应用中，依赖于应用自身完成服务的注册与发现，最典型的是Netflix提供的Eureka，还可以基于ZooKeeper或者Etcd自行实现一套服务注册机制
应用外：把应用当成黑盒，通过应用外的某种机制将服务注册到注册中心，最小化对应用的侵入性，比如Airbnb的SmartStack，HashiCorp的Consul
DNS：将服务注册为DNS的SRV记录，严格来说，是一种特殊的应用外注册方式，SkyDNS是其中的代表
2、各注册中心特性对比
| 特性 | Nacos | Eureka | Consul | ETCD | Zookeeper | CoreDNS |
|---|---|---|---|---|---|---|
| 一致性协议 | CP+AP | AP | CP | CP | CP | — |
| 健康检查 | TCP/HTTP/MYSQL/Client Beat | Client Beat | TCP/HTTP/gRPC/Cmd | Client Beat | Keep Alive | — |
| 负载均衡策略 | 权重/ metadata/Selector | Ribbon | Fabio | 轮询 | - | RoundRobin |
| 雪崩保护 | 有 | 有 | 无 | 无 | 无 | 无 |
| 自动注销实例 | 支持 | 支持 | 支持 | 支持 | 支持 | 不支持 |
| 访问协议 | HTTP/DNS | HTTP | HTTP/DNS | HTTP/GRPC | TCP | DNS |
| 监听支持 | 支持 | 支持 | 支持 | 支持(3.0) | 支持 | 不支持 |
| 多数据中心 | 支持 | 支持 | 支持 | - | 不支持 | 不支持 |
| 跨注册中心同步 | 支持 | 不支持 | 支持 | - | 不支持 | 不支持 |
| SpringCloud集成 | 支持 | 支持 | 支持 | 支持 | 支持 | 不支持 |
| Dubbo集成 | 支持 | 不支持 | 支持 | 支持 | 支持 | 不支持 |
| K8S集成 | 支持 | 不支持 | 支持 | 支持 | 不支持 | 不支持 |
实践中，在 CAP 的权衡中，注册中心的可用性比数据强一致性更宝贵，所以整体设计更应该偏向 AP，而非 CP，注册中心不能因为自身的任何原因破坏服务之间本身的可连通性
Eureka
Eureka 遵循AP原理中的「AP」原则，Eureka的集群中，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性），当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。
Consul
Consul 遵循CAP原理中的「CP」原则，保证了强一致性和分区容错性。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 ；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用。
Zookeeper
Zookeeper 遵循CAP原理中的「CP」原则，任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的，不能保证服务可用性。
ETCD
ETCD遵循CAP原理中的「CP」原则，在选主完成前会导致服务不可用。
Nacos
Nacos 的注册中心支持 CP 也支持 AP。
参考链接：
https://glory.blog.csdn.net/article/details/100023415
https://blog.csdn.net/u012921921/article/details/106521181
https://blog.csdn.net/qq_42046105/article/details/123436832
https://blog.csdn.net/weixin_41605937/article/details/121885248
如有不对，烦请指出，感谢~
