How We Solved Authentication and Authorization in Our Microservice Architecture
构建微服务中如何实现认证和授权，本文谈了�用jwt和oauth2的做法。
Let Go of the Learning Baggage
让自己有时间分心，喝杯咖啡，和同事聊聊天，出去散个步，而不是埋头工作，让学习或者工作给你带你焦虑，那要得不偿失。
So the next time you look up from that proposal on the new infrastructure schematics and see that the sun is shining, go for a walk, notice where you are, and give your mind a chance to go into diffuse-mode and process what you’ve been focusing on all morning. And give yourself a hug for doing it.
某股份制商业银行定制化PaaS介绍
基于Rancher的PaaS方案。
-
软件架构与部署方案
方案
顶层的DCOS作为统一的管理平台，可以通过PaaS以及IaaS提供的API实现对云平台的集中管控。左侧蓝色部分是原生Rancher，DCOS与红色定制化部分通过API来访问Rancher。由于未对Rancher做任何改动，可以做到对Rancher版本大于1.2的平滑升级。
-
角色与权限模型
用户及权限 资源管理
网络部分
- 由于金融行业对网络安全性方面的要求比较苛刻，而Rancher所能够提供的均是基于某个环境内部的overlay网络。Overlay必然会导致很多报文无法被安全设备透明的过滤，这是行业内无法接受的；因此，必须采用扁平网络。
- 出于安全的考虑，会出现同一个stack内部的多个service需要分别部署到不同的网络分区的需求，采用当前Rancher的managed网络显然无法满足需求；因此，必须支持多网络。
存储部分
客户PaaS在存储部分最终选定NFS作为其存储方案，前期也有讨论过使用ceph等，这部分我在之前的文章（探讨容器中使用块存储）中也有专门分析过为什么不选用那种方案。
由于单个租户可以拥有多个网络（也就是多个Rancher环境），而在Rancher中Rancher-NFS driver所创建volume是基于环境层面的。为了能够将该volume映射到租户层面，我们在抽象层中做了这层映射操作。
应用编排
- 弹性伸缩
对弹性伸缩功能的实现根据策略的类型不同大致分为两种：
基于时间的策略，该策略主要是对当前时间与策略时间区间做匹配，一旦发现进入到基于时间的策略的时间区间就基于微服务的索引，找到并更改目标微服务的容器数量；
基于内存和CPU利用率的策略本身并不监测CPU和内存信息，而是依赖于监控模块。在应用编排侧添加或更新了某个微服务的弹性伸缩策略后，弹性伸缩模块会将对这个微服务的弹性伸缩策略转换为监控告警策略下发到监控模块；同时，监听来自监控告警模块的告警信息。当收到告警时，弹性伸缩就从自己维护的映射表中找到是具体触发该告警的微服务，然后基于一系列规则来决定是否伸缩微服务的容器数量以及一次调整多少个。
-
日志收集
PaaS对日志的收集主要按照日志的来源可分为三种类型：- 主机日志收集；
- 容器日志收集；
- 应用日志收集；
监控告警
镜像仓库
