一、服务注册中心的由来
公司主营业务：网站制作、网站设计、移动网站开发等业务。帮助企业客户真正实现互联网宣传，提高企业的竞争能力。创新互联是一支青春激扬、勤奋敬业、活力青春激扬、勤奋敬业、活力澎湃、和谐高效的团队。公司秉承以“开放、自由、严谨、自律”为核心的企业文化，感谢他们对我们的高要求，感谢他们从不同领域给我们带来的挑战，让我们激情的团队有机会用头脑与智慧不断的给客户带来惊喜。创新互联推出苍溪免费做网站回馈大家。
假如没有服务注册中心，我们会干些什么事情呢？
在传统行业的项目架构中以下的方案最为常见了：
这种架构开发、部署都是最简单的，一般适用于中小企业访问量并不是太多的情况下，各个系统服务一台机器就搞定了。系统之间的调用也是拿到对方的IP+PORT直接连接。
接下来可能因为应用B开始访问量大了，单台机器已经不能满足我们的需求，于是一些反向代理工具应运而出，其中比较常见的有Apache、Nigix，架构演变为：
相比之前的应用B的单台机器访问，这种nginx代理的方式减轻了服务器的压力，但是可能会出现Nginx挂了，那么整个服务也不可用，于是又来了这么一套架构：
这样看方案算是完美了吧。然后事情并不是想象的那么一帆风顺，这还只是应用A调用一个应用B，如果应用A调用的可能是应用B、C、D、E...，这种完全就不知道他后面到底还想干嘛，这种架构看似可以，但是绝对会累死运维的（nginx的配置将会非常混乱，直接导致运维不干了）。
服务注册中心干些什么事情呢？
上面提到的那种靠人力（主要是运维干的事情）比较繁琐，还不好维护，有这么几点不方便：应用服务的地址变了、双十一搞活动服务器新增等等。那么我们可以有这么的一种架构：
服务注册中心主要是维护各个应用服务的ip+port列表，并保持与各应用服务的通讯，在一定时间间隔内进行心跳检测，如果心跳不能到达则对服务IP列表进行剔除，并同时通知给其它应用服务进行更新。同样要是有新增的服务进来，应用服务会向注册中心进行注册，服务注册中心将通知给其它应用进行更新。每个应用都有需要调用对应应用服务的地址列表，这样在进行调用时只要处理客户负载杂均衡即可。
二、微服务注册中心
1.Zookeeper
ZooKeeper是一个分布式的，开放源码的分布式应用程序协调服务，是Google的Chubby一个开源的实现，是Hadoop和Hbase的重要组件。它是一个为分布式应用提供一致性服务的软件，提供的功能包括：配置维护、域名服务、分布式同步、组服务等。
上面的话直接摘抄百度百科的内容，国内很多公司做分布式开发最初的选型大部分都是采用dubbo框架。dubbo框架注册中心主要使用zookeeper。zookeeper服务端与客户端的底层通讯为netty。zookeeper采用CAP理论中的CP，一般集群部署最少需要3台机器。
2.Euraka
先来看一下euraka的架构图：
Register：服务注册
当Eureka客户端向Eureka Server注册时，它提供自身的元数据，比如IP地址、端口，运行状况指示符URL，主页等。
Renew：服务续约
Eureka客户会每隔30秒发送一次心跳来续约。 通过续约来告知Eureka Server该Eureka客户仍然存在，没有出现问题。 正常情况下，如果Eureka Server在90秒没有收到Eureka客户的续约，它会将实例从其注册表中删除。 建议不要更改续约间隔。
Fetch Registries：获取注册列表信息
Eureka客户端从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与Eureka客户端的缓存信息不同， Eureka客户端自动处理。如果由于某种原因导致注册列表信息不能及时匹配，Eureka客户端则会重新获取整个注册表信息。 Eureka服务器缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka客户端和Eureka 服务器可以使用JSON / XML格式进行通讯。在默认的情况下Eureka客户端使用压缩JSON格式来获取注册列表的信息。
Cancel：服务下线
Eureka客户端在程序关闭时向Eureka服务器发送取消请求。 发送请求后，该客户端实例信息将从服务器的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容：
DiscoveryManager.getInstance().shutdownComponent()；
Eviction 服务剔除
在默认的情况下，当Eureka客户端连续90秒没有向Eureka服务器发送服务续约，即心跳，Eureka服务器会将该服务实例从服务注册列表删除，即服务剔除。
自我保护机制：
既然Eureka Server会定时剔除超时没有续约的服务，那就有可能出现一种场景，网络一段时间内发生了 异常，所有的服务都没能够进行续约，Eureka Server就把所有的服务都剔除了，这样显然不太合理。所以，就有了 自我保护机制，当短时间内，统计续约失败的比例，如果达到一定阈值，则会触发自我保护的机制，在该机制下， Eureka Server不会剔除任何的微服务，等到正常后，再退出自我保护机制。自我保护开关(eureka.server.enableself-preservation: false)
3.Consul
consul推荐的架构图：
Consul不像Euraka的部署那么简单，他是go语言开发的，需要运维单独部署，有提供java的客户端连接，采用的是CAP的CP。
4.Nacos
Euraka是Spring Cloud Netflix早期版本中推荐使用的，后来euraka1.0版本不再维护，euraka2.0已经闭源，导致很多新项目基于Spring Cloud Netflix 开发的选型变迁为Consul.
Nacos是阿里开源的服务注册中心，它可以与spring cloud aliaba集成使用。
Nacos的官方介绍：
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您实现动态服务发现、服务配置管理、服务及流量管理。
Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构(例如微服务范式、云原生范式)的服务基础设施。
Nacos 地图
Nacos 生态图
如 Nacos 全景图所示，Nacos 无缝支持一些主流的开源生态，例如
Spring Cloud
Apache Dubbo and Dubbo Mesh TODO
Kubernetes and CNCF TODO
三、服务注册与发现技术选型
以下是来自网上的一个分享：
除了上述的几种以外，笔者更推荐使用Nacos作为服务注册中心。
推荐理由：
Nacos服务注册表结构Mapnamespace, Mapgroup::serviceName, Service采用多层次Map结构，控制的颗粒度更细，支持金丝雀模式发布，心跳同步机制也更快速，服务更新更及时。
讨论哪个语言更好，就像在争论姚明和刘翔谁是更优秀的运动员。因为各自的坐标象限不同，常常会陷入一个难有结论怪圈。
所以本文绝不是在说Golang是比其他语言更好的语言。Golang只是最值得推荐的语言，尤其适合快速成长中的后端研发团队。
我推荐Golang的主要理由，并不是技术性的要素：不是他的高并发能力，编译的速度，跨平台能力，内存效率，也不是社区的活跃度等等。
事实上，创业之后，或者说成为一个技术管理者之后，技术优点就已经不再是我推荐任何一种语言的关键因素了。
因为，对于一个研发团队来说，项目成败的关键因素是：成本、质量和时间！
1、人力资源的成本
人力资源是研发团队最重要的资源，也是唯一的资源。其成本不仅仅是团队要支付的薪资代价。也包括获得资源的难易程度，例如招聘和培训的速度。以及维持资源，也就是保持员工满意度或者说士气的代价，也就是管理成本。（上述成本不仅指钱，时间也是非常昂贵的成本）
Golang有一系列特点，使它既容易上手，又易于维护。Golang可以让初阶和中阶工程师，经过少许培训，就写出相当不错的代码。直接点说，一票1-2年经验少许灵性的年轻工程师转Golang，只要少许指导，很快就可以写出高并发高负载能力生产级别的代码，而且质量相当有保证。而同样的工程，如果用C++或java等语言，则需要至少3-5年经验的工程师来完成，同时质量还是要让人担心。
那么，对于团队特别是成长型的或创业团队来说，现在有Golang这样一种语言，可以让大量初阶和中级工程师承担主要开发工作，还能保证相当优秀的结果，从资金成本和时间成本控制的角度，简直就是美梦成真。
2、项目研发的效率
说到高并发高负载，让我不能不想起nginx。nginx在2004年从web server领域横空出世，所向披靡。精巧严谨易于维护和扩展的代码结构，也是教科书级别的。
但是要知道，一个用C写出一个nginx，是需要世界上最优秀的工程师的。这样的工程师，不仅团队里面没有，连遇到一个都很难。
可现在，我再告诉你，一个使用Golang的中级工程师，就已经可以写出性能与nginx相近的高并发高负载应用。而且不仅性能相近，而且需要的代码行数和开发时间也短很多。这对于团队成员来说，这很可能是决定生死存亡还是走上人生巅峰的区别。
--
总之：
对于团队管理者来说，Golang可以让团队用更低的人力成本，更快的速度，更高的质量，完成项目研发。
对于工程师来说，Golang可以让人有更多的时间去思考和生活。
所以，我推荐Golang。
有必要,因为Nginx是专业的完备的HTTP/HTTPS服务器,像很多服务如PHP-FPM,Java Tomcat,Node普遍都躲在Nginx后面跑,这样做的好处就是后端语言只处理自己的请求,不需要处理各种静态资源(img/css/js/file)的请求,比如用户下载一个大文件,如果是后端语言自己处理,那肯定会拖累应用性能,但如果委托给Nginx(X-Accel-Redirect: file_path),Nginx就会用自己的AIO线程池来实现大文件下载支持,就不需要后端语言费力去折腾.
网关=反向代理+负载均衡+各种策略，技术实现也有多种多样，有基于 nginx 使用 lua 的实现，比如 openresty、kong；也有基于 zuul 的通用网关；还有就是 golang 的网关，比如 tyk。
这篇文章主要是讲如何基于 golang 实现一个简单的网关。
转自： troy.wang/docs/golang/posts/golang-gateway/
整理：go语言钟文文档:
启动两个后端 web 服务（代码）
这里使用命令行工具进行测试
具体代码
直接使用基础库 httputil 提供的NewSingleHostReverseProxy即可，返回的reverseProxy对象实现了serveHttp方法，因此可以直接作为 handler。
具体代码
director中定义回调函数，入参为*http.Request，决定如何构造向后端的请求，比如 host 是否向后传递，是否进行 url 重写，对于 header 的处理，后端 target 的选择等，都可以在这里完成。
director在这里具体做了：
modifyResponse中定义回调函数，入参为*http.Response，用于修改响应的信息，比如响应的 Body，响应的 Header 等信息。
最终依旧是返回一个ReverseProxy，然后将这个对象作为 handler 传入即可。
参考 2.2 中的NewSingleHostReverseProxy，只需要实现一个类似的、支持多 targets 的方法即可，具体实现见后面。
作为一个网关服务，在上面 2.3 的基础上，需要支持必要的负载均衡策略，比如：
随便 random 一个整数作为索引，然后取对应的地址即可，实现比较简单。
具体代码
使用curIndex进行累加计数，一旦超过 rss 数组的长度，则重置。
具体代码
轮询带权重，如果使用计数递减的方式，如果权重是5,1,1那么后端 rs 依次为a,a,a,a,a,b,c,a,a,a,a…，其中 a 后端会瞬间压力过大；参考 nginx 内部的加权轮询，或者应该称之为平滑加权轮询，思路是：
后端真实节点包含三个权重：
操作步骤：
具体代码
一致性 hash 算法，主要是用于分布式 cache 热点/命中问题；这里用于基于某 key 的 hash 值，路由到固定后端，但是只能是基本满足流量绑定，一旦后端目标节点故障，会自动平移到环上最近的那么个节点。
实现：
具体代码
每一种不同的负载均衡算法，只需要实现添加以及获取的接口即可。
然后使用工厂方法，根据传入的参数，决定使用哪种负载均衡策略。
具体代码
作为网关，中间件必不可少，这类包括请求响应的模式，一般称作洋葱模式，每一层都是中间件，一层层进去，然后一层层出来。
中间件的实现一般有两种，一种是使用数组，然后配合 index 计数；一种是链式调用。
具体代码
当客户端在 发出POST请求时/albums，您希望将请求正文中描述的专辑添加到现有专辑数据中。
为此，您将编写以下内容：
1、编写代码
a.添加代码以将专辑数据添加到专辑列表。
在此代码中：
1）用于Context.BindJSON 将请求正文绑定到newAlbum。
2） album将从 JSON 初始化的结构附加到albums 切片。
3）向响应添加201状态代码，以及表示您添加的专辑的 JSON。
b.更改您的main函数，使其包含该router.POST函数，如下所示。
在此代码中：
1）将路径中的POST方法与 /albumspostAlbums函数相关联。
使用 Gin，您可以将处理程序与 HTTP 方法和路径组合相关联。这样，您可以根据客户端使用的方法将发送到单个路径的请求单独路由。
a.如果服务器从上一节开始仍在运行，请停止它。
b.从包含 main.go 的目录中的命令行，运行代码。
c.从不同的命令行窗口，用于curl向正在运行的 Web 服务发出请求。
该命令应显示添加专辑的标题和 JSON。
d.与上一节一样，使用curl检索完整的专辑列表，您可以使用它来确认添加了新专辑。
该命令应显示专辑列表。
当客户端向 发出请求时GET /albums/[id]，您希望返回 ID 与id路径参数匹配的专辑。
为此，您将：
a.在您在上一节中添加的函数下方postAlbums，粘贴以下代码以检索特定专辑。
此getAlbumByID函数将提取请求路径中的 ID，然后找到匹配的专辑。
在此代码中：
（1）Context.Param用于从 URL 中检索id路径参数。当您将此处理程序映射到路径时，您将在路径中包含参数的占位符。
（2）循环album切片中的结构，寻找其ID 字段值与id参数值匹配的结构。如果找到，则将该album结构序列化为 JSON，并将其作为带有200 OK HTTP 代码的响应返回。
如上所述，实际使用中的服务可能会使用数据库查询来执行此查找。
（3）如果找不到专辑，则返回 HTTP 404错误。
b.最后，更改您的main，使其包含对router.GET的新调用，路径现在为/albums/:id ，如以下示例所示。
在此代码中：
（1）将/albums/:id路径与getAlbumByID功能相关联。在 Gin 中，路径中项目前面的冒号表示该项目是路径参数。
a.如果服务器从上一节开始仍在运行，请停止它。
b.在包含 main.go 的目录中的命令行中，运行代码以启动服务器。
c.从不同的命令行窗口，用于curl向正在运行的 Web 服务发出请求。
该命令应显示您使用其 ID 的专辑的 JSON。如果找不到专辑，您将收到带有错误消息的 JSON。
恭喜！您刚刚使用 Go 和 Gin 编写了一个简单的 RESTful Web 服务。
本节包含您使用本教程构建的应用程序的代码。
适合。框架足够成熟了 A Survey of 5 Go Web Frameworks
小型项目你甚至不用框架，用net/http http - The Go Programming Language
常用库也成熟了 Top - Go Search
golang的web后端即使不concurrent也比php，ruby，python快很多很多
golang里用concurrent真的非常方便，非常非常快，超大web项目golang scale成本低
如果你想，golang的部署可以比php更方便，使用go get和http.ServeAndListen()可以不用nginx和apache
对于文件改动重新编译其实并不是大问题，看pilu/fresh · GitHub，其实你自己写shell脚本（也可以直接用go写，因为它本身就是系统语言）监控文件系统改动然后自动重新build，即使是C/C++的项目这也不是大问题，人们不用C/C++写web是因为它们不是写web app的最佳选择
golang写的代码编译通过后，要比scripting language鲁棒，因为go compiler强制一些最佳实践
