《大话云原生》系列文章 冀望用最艰深、简略的语言阐明云原生生态系统内的组成及利用关系。此专栏的前两篇文章
- 《【大话云原生】煮饺子与 docker、kubernetes 之间的关系》
- 《【大话云原生】负载平衡篇 - 小饭馆的流量变大了》
欢送品鉴！
一、服务接待核心与微服务网关
老婆最近快过生日了，我许可她去游览住一次五星级酒店。我查看了目的地的五星级酒店的价格，决定只住一天。第一次住所以查看了一下特色服务项目：擦鞋、熨烫衣物、机场绿色通道、专车接送等等，简直在酒店场合范畴内所有能够让你懒出奇观的我的项目都能够提供。没出息的时不我待，插入房卡，一键拨通前台电话要求提供衣物熨烫服务，不一会服务人员就将衣物取走了，20 分钟后送了回来。真是太不便了！
五星级酒店所有的服务只有一个入口：服务接待核心。这个服务接待核心和微服务软件架构中的网关性能真的是殊途同归啊
- 提供服务申请的惟一入口，也是面向用户提供服务惟一入口
- 对申请信息进行平安验证，因为我在入住时曾经取得了房卡，这个房卡就像是在利用开发中的 token(JWT、OAuth 等登录认证形式都会公布令牌)
- 有了这个房卡（令牌），咱们能力通过服务接待核心申请服务项目。同样微服务网关也会进行权限验证后，才会提供 API 申请服务。
二、酒店外部通信录与服务注册核心
其实咱们认真想一想，服务接待核心（微服务网关）提供面向用户的服务入口。那么酒店外部部门之间是不是只对外提供服务，不对内提供服务？显然不是的。举几个例子：
- 各种部们简直都依赖采购部洽购的物品，所以肯定会和采购部申请服务用品
- 服务部给客户送餐的时候，肯定须要和餐饮部进行通信
对于微服务架构来说也是一样的，有的微服务间接面向用户提供服务，有的微服务是为零碎外部服务提供服务。所以正确的架构形式是上面这样的。
当服务之间存在调用关系，就存在一个问题：各个部门（各个服务）之间如何分割，联系方式是什么？其实就是须要建设一个酒店外部的通信录，这个通信录只在酒店外部应用。对于微服务架构而言同样须要这样一个通信录
- 在服务创立的时候，把本人的联系方式 (ip、端口、服务名称) 写在“通信录”上
- 在服务下线的时候，本人的联系方式从“通信录”上被划掉
这个服务之间的“通信录”，对于微服务架构而言就被叫做:服务注册核心。常见的微服务注册核心有 nacos、eureka、zookeeper 等等。
三、微服务的高可用
咱们再思考一个问题，这么大的酒店是不是只有一个服务部，只有一个采购部？当然不会，即便只有一个部门，也会分成多个小组。比方：服务部 A 小组负责 1 - 3 楼、服务部小组 B 负责 4 - 6 楼，顺次类推（这其实就是一个负载平衡算法）。所以进一步欠缺的架构应该是上面这样的。
- 一个部门分成多个组，一旦 A 组忙不过来，B 组齐全能够过去帮忙。但在大多数状况下依照负载算法各司其职。
- 一个好汉三个棒，有事大家一起扛。这在分布式服务架构中就是一种高可用的体现。
- 不会因为一个小组的罢工导致整个服务部门瘫痪。这在服务架构中体现的是容错性和正本备份机制。
每个部门尽管分成了多个小组，但也会有 该部门的对立的管理制度、服务规范 。这个制度及服务规范对立制订，对立配置管理。对于微服务架构来说，也会有一个中央保留某一类微服务的对立配置信息，它就是 服务配置管理核心。咱们常见的服务配置管理核心有 nacos、Spring Cloud Config 等。（nacos 既能够充当服务注册核心，也能够充当配置管理核心）
欢送关注我的博客，更多精品常识合集
本文转载注明出处（必须带连贯，不能只转文字）：字母哥博客 – zimug.com
感觉对您有帮忙的话，帮我点赞、分享！您的反对是我不竭的创作能源！。另外，笔者最近一段时间输入了如下的精品内容，期待您的关注。
- 《kafka 修炼之道》
- 《手摸手教你学 Spring Boot2.0》
- 《Spring Security-JWT-OAuth2 一本通》
- 《实战前后端拆散 RBAC 权限管理系统》
- 《实战 SpringCloud 微服务从青铜到王者》