一直以来思考的一个架构实现方案：基于曾经做过的项目以及未来想做的项目

    1. 单点登录和Session共享
    2. 路由
    3. 权限认证和授权
    4. 负载均衡，熔断和限流
    5. 缓存
    6. 可自由切换的多数据源

    image.png

    单点登录和Session共享

    不同微服务之间要共享session和用户甚至权限信息是非常重要的，不然会出现频发的登录和服务中断的情况；早期我们使用了spring session cookie + Redis的方案；但是对小程序和App不够友好；后来换成JWT的方案，但是随之而来的是jwt载荷太大，需要放到jwt中用户和权限的信息太多，更新jwt麻烦，同时颁发给前端的数据量太大，后端需要频繁的处理jwt从中获得用户信息；于是又改成了spring session + header + redis的方案和 spring session + token + redis的方案；后端颁发授权给前端，无论前端在header中还是在token中都可以进行鉴权，然后确定用户session，并通过redis进行共享；目前感觉这个技术方案比较好用；

    路由

    其实有三种方式可以选择nginx，zuul，spring gateway；
    nginx其实性能是最好的，配置上如果熟悉的话是非常灵活和简单的，但是也是复杂的，因为不是spring cloud技术中的一员，所以无法和微服务进行通过编程的方式提供更加灵活和高要求的后端配合；

    zuul是一个非常强大和灵活的的选择，唯一的缺点是不支持websocket；
    spring gateway 是旨在取代zuul而产生的，对websocket支持良好，而且提供个更丰富和强大的配置方式，提供了很多的额外附加功能，比如限流和熔断；随之而来的代价是臃肿和复杂，在性能上不同的场景下性能不如zuul；不过目前来说还是建议大家选择这个技术方案；

    授权和认证

    我们经常把他们合在一起说，其实他们是密不可分的两部分，而且非常容易让人混淆，但是最好把这两个分开来看；

    authentication(认证) 我们确定用户是否存在是否是我们的用户，是什么身份
    Authorize（授权）确定用户是否有权限访问对应的资源；

    这里面我所熟知的是shiro 和 spring security两个框架都可以方便的进行完成上面的两个工作；
    shiro 更简单更灵活，这也是网上很多资料，很多推荐的原因，而且确实如此；
    spring security 其实不复杂，只是理解上比较难，而且可以在多个层面上实现，而且实现完成后很多人不知道为什么起作用，不是线性的编程，而是框架预留了一个编程切口，实现具体的中间部分就OK了；但是更强大和spring 结合的更紧密，同时有一个最优解，可以只要实现几个接口用很少的代码就能实现认证和授权；

    这个最优解就是针对uri 进行判断用户是否可以合法的访问；实现认证AuthenticationManagerBuilder具体逻辑，实现accessDecisionManager接管所有的访问并根据业务逻辑做出访问控制；

    负载均衡，熔断和限流

    如果使用了gateway 来进行路由可以非常方便的使用这个三个技术，为什么要放在一起说因为这三个技术是为了保护我们后面的微服务更高质量的提供对外的服务；
    负载均衡：当我们一个服务处理不过来所有请求的时候我们就用两个，两个不行我们就用三个，甚至成千上万个来保证我们服务的高可用性，同时使用负载均衡策略合理的分配流量；
    熔断：即使我们对服务的可用性提供的再周全，都不可能再极端情况下保证服务的可用性的时候，为了避免服务崩溃和服务调用之间的链式雪崩我们不得已引入熔断机制；相当于为服务增加一个保险丝，通过牺牲局部的不可用或者降级来保证全局的可用性；
    限流：是为了让流量匹配服务时变的有序和可控，不至于我们频繁的熔断来保护服务，同时为负载均衡和扩容创造判断和时机；

    上面的几乎都设计到策略，有好几种策略可以选择，也可以根据自己的业务时间自己实现需要的策略；

    缓存
    每个单体微服务都需要拥有自己的缓存，相同服务尽量公用缓存，这样能提高自己的吞吐能力和保护数据库的IO，对性能的提升非常重要，尤其是高并发的读请求的时候；像用户和授权这些类型的涉及到很多读操作尽量不要吝啬缓存；

    缓存框架和缓存机制也有很多，目前我还谈不上好坏，因为目前我还没遇到缓存不够用导致数据库不堪重负的情况，相反因为缓存带来的开发的不便利反而让开发人员回避缓存的使用是一个难题，我觉得目前能普及缓存的使用其实就是一种进步；

    可自由切换的多数据源

    一个微服务如果可以自由的切换多数据源，就可以轻松的实现跨库分库访问的能力了，这样我们就可以再分布式数据访问中，再数据库的设计中获得更强的大数据访问能力；

    好在这项技术不难，希望如果有大数据访问要求的架构设计时可以使用这种方式来实现，并赋予单个微服务的多数据访问能力；

    OpenFeign和消息服务以及websocket
    openfeign 是服务间相互调用并及时返回
    消息服务是 异步的消息通知
    两种方式的数据传递需要合理的利用可以极高数据传输

    分布式事物的CAP原则

    CI/CD

    受益于公司去年推广的开发工作流技术，我们在开发上实现了持续集成和持续开发，实现了部署和运维的自动化，这在加快开发进度和解放生产力上有极大的提高；

    这里面涉及到两个技术Work flow 和 Jenkins 云栖大会上见到了更多的相关工具和思路；

    DevOps

    CI/CD的使用以及Docker和容器的使用让Devops变的更加的简单轻松，只需要Dockerfile的配置就可以完成；涉及到专业技术就不表述了；

    上面两个技术记得是朱文乾和马伟负责推广和普及的，那个时候这个组织蛮好的应该更好的组织，继续下去；