本論文では、DNS、負荷分散、長い接続、APIゲートウェイ、PUSHプッシュ、マイクロサービス、分散トランザクションおよび関連サポートの基本的なサービスを含む、インターネットの技術的基盤について説明します。主にあなたの参照を与えることを期待して、勉強します。
全体的なアーキテクチャ
APP、PCだけでなく、伝統的なDNSサービスLocalDNSを通じて、発信者としての第三者は、ロードバランサは、IP、APPはHttpDNS方法によって、より柔軟かつ正確なリアルタイムのドメイン名解決サービスを実装することができ得ます。
ロード・バランサを介して到達ユニファイドアクセスレイヤは、統一されたアクセスレイヤは、長い接続を維持します。
入口マイクロ責任プロトコル変換、要求のルーティング、認証、認可、フロー制御、データキャッシュとしてゲートウェイAPIおよびサービス。
ビジネスサーバーは、IM、通知機能として、PUSH方式を押すことで最後までリアルタイムのプッシュを実現しています。
Business Serverの実装独自のRPCプロトコルを介して相互間の通話、およびNATゲートウェイを介して外部のサードパーティのサービスへの呼び出し。
DNS
伝統的なDNS
DNS（ドメインネームシステム）ドメインネームシステム、変換のドメイン名とIPアドレスを使用する分散型ネットワーク・ディレクトリ・サービスは、マシンのIPアドレスを覚えていなくても、インターネットへの人々より多くの便利なアクセスを行うことができます。
次のようにDNS解決プロセスである：
クライアント再帰クエリLocalDNS（典型的には、ISPインターネットサービスプロバイダエッジDNSサーバ）IPを得ること
LocalDNS反復がIPを取得するために照会し、つまりは常にドメインネームサーバアドレスのクエリを取得します
HttpDNS
モバイル解析DNSプロトコルベースのオペレータローカルDNSに解決要求を開始する伝統的な方法を置き換えるために、DNSサーバのドメイン名解決要求を送信する（HttpDNS）HTTPベースのプロトコル、ドメイン名は、モバイルインターネットを解決するため、ローカルDNSハイジャックとのクロスネットワークアクセスの問題を回避することができ異常によって引き起こされるサービスのDNSの問題。
テンセントクラウドHttpDNS参考として、従来LocalDNS比較に比べて利点を有します。
ロードバランシング
アドレスパフォーマンスの問題にするためにだけでなく、1台のマシン上の1つの点で、複数のマシンは、トラフィック要求は、上記の別のサーバーに分散され、負荷分散を水平スケーリングする必要があります。
客户端的流量首先会到达负载均衡服务器，由负载均衡服务器通过一定的调度算法将流量分发到不同的应用服务器上面，同时负载均衡服务器也会对应用服务器做周期性的健康检查，当发现故障节点时便动态的将节点从应用服务器集群中剔除，以此来保证应用的高可用。
网络负载均衡主要有硬件与软件两种实现方式，主流负载均衡解决方案中，硬件厂商以F5为代表，软件主要为LVS、NGINX、HAProxy。
技术原理上分为L4四层负载均衡和L7七层负载均衡。
L4 vs L7
L4四层负载均衡工作于处于OSI模型的传输层，主要工作是转发。它在接收到客户端报文后，需要了解传输层的协议内容，根据预设的转发模式和调度算法将报文转发到应用服务器。以TCP为例，当一个TCP连接的初始SYN报文到达时，调度器就选择一台服务器，将报文转发给它。此后通过查发报文的IP和TCP报文头地址，保证此连接的后继报文被转发到该服务器。
L7七层负载均衡工作在OSI模型的应用层，主要工作就是代理。七层负载均衡会与客户端建立一条完整的连接并将应用层的请求解析出来，再按照调度算法选择一个应用服务器，并与应用服务器建立另外一条连接将请求发送过去。
LVS转发模式
LVS（IP负载均衡技术）工作在L4四层以下，转发模式有：DR模式、NAT模式、TUNNEL模式、FULL NAT模式。
DR模式（直接路由）
改写请求报文的MAC地址，将请求发送到真实服务器，而真实服务器将响应直接返回给客户。要求调度器与真实服务器都有一块网卡连在同一物理网段上，并且真实服务器需要配置VIP。
NAT模式 （网络地址转换）
调度器重写请求报文的目标地址，根据预设的调度算法，将请求分派给后端的真实服务器；真实服务器的响应报文通过调度器时，报文的源地址被重写，再返回给客户，完成整个负载调度过程。要求负载均衡需要以网关的形式存在于网络中。
TUNNEL模式
调度器把请求报文通过IP隧道转发至真实服务器，而真实服务器将响应直接返回给客户，所以调度器只处理请求报文。要求真实服务器支持隧道协议和配置VIP。
FULL NAT模式
在NAT模式的基础上做一次源地址转换（即SNAT），做SNAT的好处是可以让应答流量经过正常的三层路由回到负载均衡上，这样负载均衡就不需要以网关的形式存在于网络中了。性能要逊色于NAT模式，真实服务器会丢失客户端的真实IP地址。
调度算法
轮询
将外部请求按顺序轮流分配到集群中的真实服务器上，它均等地对待每一台服务器，而不管服务器上实际的连接数和系统负载。
加权轮询
权值越大分配到的访问概率越高，主要用于后端每台服务器性能不均衡的情况下，达到合理有效的地利用主机资源。
最少连接
将网络请求调度到已建立的链接数最少的服务器上。如果集群系统的真实服务器具有相近的系统性能，采用"最小连接"调度算法可以较好地均衡负载
哈希
将指定的Key的哈希值与服务器数目进行取模运算，获取要求的服务器的序号
一致性哈希
考虑到分布式系统每个节点都有可能失效，并且新的节点很可能动态的增加进来，一致性哈希可以保证当系统的节点数目发生变化时尽可能减少访问节点的移动。
API网关
API网关（API Gateway）是一个服务器集群，对外的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，对外提供REST/HTTP的访问API。同时还具有其它非业务相关的职责，如身份验证、监控、负载均衡、缓存、流量控制等。
API管理
API网关核心功能是 API 管理。提供 API
的完整生命周期管理，包括创建、维护、发布、运行、下线等基础功能；提供测试，预发布，发布等多种环境；提供版本管理，版本回滚。
API配置包括前端配置和后端配置。前端配置指的是Http相关的配置，如HTTP 方法、URL路径，请求参数等。后端配置指的是微服务的相关配置，如服务名称、服务参数等。这样通过API配置，就完成了前端Http到后端微服务的转换。
全异步
由于API网关主要处理的是网络I/O，那么通过非阻塞I/O以及I/O多路复用，就可以达到使用少量线程承载海量并发处理，避免线程上下文切换，大大增加系统吞吐量，减少机器成本。
常用解决方案有 Tomcat/Jetty+NIO+servlet3.1 和Netty+NIO，这里推荐Netty+NIO，能实现更高的吞吐量。Spring 5.0 推出的WebFlux反应式编程模型，特点是异步的、事件驱动的、非阻塞，内部就是基于Netty+NIO 或者Servlet 3.1 Non-Blocking IO容器 实现的。
链式处理
链式处理即通过责任链模式，基于 Filter 链的方式提供了网关基本的功能，例如：路由、协议转换、缓存、限流、监控、日志。也可以根据实际的业务需要进行扩展，但注意不要做耗时操作。
Spring cloud gateway （基于 Spring WebFlux）的工作机制大体如下：
Gateway 接收客户端请求。
客户端请求与路由信息进行匹配，匹配成功的才能够被发往相应的下游服务。
请求经过 Filter 过滤器链，执行 pre 处理逻辑，如修改请求头信息等。
请求被转发至下游服务并返回响应。
响应经过 Filter 过滤器链，执行 post 处理逻辑。
向客户端响应应答。
请求限流
请求限流是在面对未知流量的情况下，防止系统被冲垮的最后一道有效的防线。可以针对集群、业务系统和具体API维度进行限流。
具体实现可以分为集群版和单机版，区别就是集群版是使用后端统一缓存如Redis存储数据，但有一定的性能损耗；单机版则在本机内存中进行存储（推荐）。
常用的限流算法：计数器、漏桶、令牌桶（推荐）
熔断降级
服务熔断
当下游的服务因为某种原因突然变得不可用或响应过慢，上游服务为了保证自己整体服务的可用性，不再继续调用目标服务，直接返回，快速释放资源。如果目标服务情况好转则恢复调用。
熔断是为了解决服务雪崩，特别是在微服务体系下，通常在框架层面进行处理。内部机制采用的是断路器模式，其内部状态转换图如下：
服务降级
当负荷超出系统整体负载承受能力时，为了保证核心服务的可用，通常可以对非核心服务进行降级，如果返回缓存内容或者直接返回。
服务降级的粒度可以是API维度、功能维度、甚至是系统维度，但是都需要事前进行服务级别的梳理和定义。
真实场景下，通常是在服务器负载超出阈值报警之后，管理员决定是扩容还是降级。
业务隔离
API网关统一了非业务层面的处理，但如果有业务处理的逻辑，不同业务之间就可能会相互影响。要进行业务系统的隔离，通常可以采用线程池隔离和集群隔离，但对于Java而言，线程是比较重的资源，推荐使用集群隔离。
PUSH推送
消息推送系统 针对不同的场景推出多种推送类型，满足用户的个性化推送需求，并集成了苹果、华为、小米、FCM
等厂商渠道的推送功能，在提供控制台快速推送能力的同时，也提供了服务端接入方案，方便用户快速集成移动终端推送功能，与用户保持互动，从而有效地提高用户留存率，提升用户体验。
建設会社は、登録され、バインドユーザプロセス
プッシュメッセージングプロセス
ビジネスオンライン、あなたはネットワークを持っていない可能性があり際のビジネス・シナリオの多くでは、ユーザーが発生しないことがあります。そのため、MPS内のすべてのメッセージは永続的になります。ビジネスが発生すると、MPSは（TCPコネクションをプッシュするプッシュまたは自作の第三者チャネル）プッシュをしようとします。プッシュがあれば自作のチャネルは、クライアントはプッシュメッセージを受信した後、サーバは、サーバがメッセージのステータスを更新することができ、領収書を返し、ユーザの端末がTCPコネクションを持っているかどうかを判断するために、クエリキャッシュを通過します。プッシュが失敗した場合、または領収書を紛失した場合は、次回のユーザ接続が確立されると、それは再受諾メッセージ通知し、クライアントは、論理的に重いを行くだろう。
マイクロサービスシステム
著者：VectorJin
出典ます。https：//juejin.im/post/5e353a14e51d453cf422c6cb#heading-8
上記は、[自分の思考の一部、正しい私に歓迎を共有するには、あなたは少しプライベートの手紙の後に私のパートナーを懸念内部情報の関心の波を見つけるための方法ですJavaは ]あなたは〜の自由を受け取ることができます
