无线BFF，为前端开发的后端，主要由前端团队开发。
BFF可以认为是一种代理适配服务，它可以将后端服务进行聚合、适配、裁剪、这样可以为无线设备提供设备友好，方便无线设备接入访问后端的服务。
架构的好处：
随着业务的增加，带来的问题如下：
好处：
服务器端BFF也可以看做一种特殊BFF层，只是他输出的是HTML,不是Json而已。
背景：web1.0、2.0早期时代，主要是以网站形式呈现出来，大多采用前置反向代理，主要就是反向代理和负载均衡，典型的有Ngix、HAProxy,这些产品成熟稳定性能高，一般由运维团队管理。
如今：如今进入微服务时代，对路由配置、安全要求很高，这个时候就出现了很多矛盾，如传统反向代理不灵活，传统运维方式效率低下，研发人员无法做到自配置，为了解决这些问题，网关就诞生了。网关主要面向微服务，可以提供更灵活的，由研发团队自配置的能力，Netflixzuul就是这样的网关。
注意：反向代理能做的，网关也能做，由此就有了两套，但是随着技术的发展，对网关要求更高，不仅要求动态可配置，而且要求动态可编程，所以面向云原生的产品，出现了很多统一代理的概念，如envoy,Traefik
为了解决上述分两套的网关的问题，采用统一网关，架构就比较简单，所有应用同于部署，没有跨域问题，只要应用在同一个根域下。对于Web、单页应该、微服务来说，他们也有一些差异化需求的，如网关统一错误处理，web错误一般是错误页面，api出错，一般是json数据，要不要分集群，主要看你公司业务大小，业务小不建议分集群，逐步规模之后建议是要分集群。
路由映射表，是关键，常见的有基于域名，或者基于HTTP头，或者基于请求参数，我们的是基于域名的路由，所以映射表里存放的是HTTP头，
如果路由表有更新，则HttpClient也会有更新
路由配置表，例如本地的一个路由配置表
1.2认证阶段具体过程
2.1访问阶段具体过程
3.1V1版本上线后，有一些Bug出现，具体表现为：
3.2粘性会话的问题：
4.1如何来解决粘性会话带来的问题呢？
通过缓存Redis，将用户的会话存储在后台的一个Redis缓存中，好处是LB和server集群都不用去存储会话，当需要sessionID时，只需要去Redis中去获取即可，这样server集群的水平扩展性提高了。
这个service独立承担如下职责：
服务鉴权：服务鉴权认证主要是使用了token作为校验，这个令牌是一个透明令牌，所谓透明令牌，就是一个随机的无异议的字符串，和一次会话相互关联，下次访问也可以通过这个令牌访问。
引入网关gateway来解决上述问题，
不好处：
AuthService的本质，还是一个集中状态认证架构，这种架构适合于大部分比较严格的微服务认证场景，这种框架的劣势是AuthService的压力会比较大，很可能造成网站性能瓶颈。对于安全要求不太高的场景，可以采用JWT令牌校验。
3.2.重构后的V3.6架构
说明：总体是一种高性能、可扩展的认证架构,适用于安全要求不太高的场景。
结构：Header+Payload（消息体）+Signature（签名），中间使用.来区分
JWT令牌是公开可见的，任何人拿到JWT令牌，都可以去jwt.io上面去解密，看到其中内容，所以JWT不能保证信息的保密性，但是他可以保证信息的可依赖性和不可篡改性，类似现实生活中的支票签名。
6.1.HMAC流程
6.2.RSA流程
与HMAC区别就在于，secret采用RSA公钥和私钥这种签名算法（公私钥成对出现）
注意：只有在AuthServer上保存私钥，保密性好,公钥在是公开的，resourceserver拿到公钥，最多可以做解签校验，不能够篡改，加签,相比来说，HMAC比RSA要简单。
总结：JWT更适合安全不敏感场景，而透明令牌（引用令牌）更适合安全敏感场景
1、服务层（Service层），service和domain层两者共同实现业务逻辑
胖瘦领域模型孰好孰坏，业界有争论。
2、数据持久层Repository，主要负责数据库对象存储逻辑，底层一般是ORM框架，如hibernate或mybatis，Repository是领域驱动设计（DDD即Domain-DrivenDesign）的一种设计模式。
微服务测试一般需要mock数据，常见的mock分为
端到端测试:（EndtoEnd）所谓端到端测试，将整个系统看成一个黑盒子，一般通过其接口，如Api对整体业务线做整体测试。
注意：线下测试做的再多，也不能完全模拟线上，所以一般到了线上，我们一般要做灰度测试+生产监控
说明：所谓生产就绪，就是在上线交付到客户手中，要完成如下部分：
说明：云原生就是基于微服务原理而开发的应用，以容器云方式打包。在运行时，容器由运行于云基础设施之上的平台进行调度。应用开发采用持续交付和Devops实践。