time.geekbang.org
Jaising666
不能躺平，不愿秃顶的程序猿
获得徽章 16
- 引用下周志明大佬在 2020 年 QCon 大会上的分享《云原生时代，Java 的危与机》，视频地址：
time.geekbang.org，文本地址：icyfenix.cn。
1、Java 的平台无关性优势被容器削弱了很多
2、Java 面向大规模长时间运行的服务端应用设计，容器亲和性差，内存消耗、启动时间、镜像体积等都无法与云原生语言媲美
3、Java 也在做着转型努力，比如致力于脱离 JVM 直接运行原生代码的 Leyden，提前识别编译的 GraalVM，提高内存利用率的 Valhalla，以同步代码风格解决异步执行问题的 Loom，减少镜像体积的 Portola 等
从目前大规模使用的语言市场分析，Java 还是更适合应用层面，面向业务、多人协作，Rust 和 Go 成为了中间件的新兴力量，C 则持续在操作系统层面耕耘。展开评论点赞 - 《重来 3：跳出疯狂的忙碌》对 10x 程序员做了一种阐释，生产力是用来形容机器的，不是用来形容人的。
如果用生产力来形容人就会导致不断填满又不断膨胀的任务栏，追求更高的产品产出，也就是做更多的工作或花费更少的时间，机器可以 7x24 工作，但是人不能。强调生产力就意味着强调忙碌，没有闲暇也就没有思考，缺少创造性程序员就沦为了重复制造的机器。
对于程序员而言，真正追求的应该是有效性（effective），确认目标并高效完成，善于做减法，腾出的时间可以思考与休息，从而可持续发展。展开赞过 评论3 - 但是当类似的事情真的发生在身边的时候还是会觉得很奇幻。就在昨天，也就是七夕，一位同事发了邮件实名投诉部门主管与经理，直接发给了研发条线老大和公司副总裁，并抄送给了部门所有人。
他在邮件里提到自己刚刚被优化的经过，领导出尔反尔的项目管理与个人成长承诺，碍于自己的表达无处言说的工作苦衷，以及对领导认为自己负面影响的解释等等。措辞激烈，洋洋洒洒写了几千字。
对于这样的局面无疑是双输的，也会有这样的一些思考——
1、企业运转需要理性，管理手段施加人性，对于软件工程师来说竞争也是残酷的，不能持续提供价值就要面临失业风险，只卖苦劳不卖功劳难以维系
2、沟通至关重要，对于软件开发也是如此，况且还要兼任项目管理工作，系统集成项目就是软件、硬件和人件
3、管理手段如何保证业务持续，目标达成与团队稳定，很多情况下人员流动依然是头等风险，如何平衡是管理者要面临的课题
4、公司如何处理这种突发情况，澄清问题也好，抚慰情绪也好，保持其他员工信任也好，内部的结果公开发布是需要的，如何操作，静观其变展开评论点赞 - OAuth 2 设计理念分析与实践之九——Definition of OAuth 2
作为工程师或者说架构师，独立思考能力很关键，而思考的基础就是定义。OAuth 2 来自于 IETF OAuth 工作组制定的标准协议，它本身并不是单体协议，而是以颁发令牌与使用令牌为核心，大量衍生协议做扩展的协议族，就像 HTTP 一样。
而我们常说的 OAuth 2 其实指的是这两个核心协议，即 2012 年发布的获取令牌的协议 RFC 6749，以及伴随规范定义的 bearer 令牌协议 RFC 6750。datatracker.ietf.org 和 datatracker.ietf.org。它俩构成了 OAuth 2.0 的核心。
另一方面，从使用者角度来看，学习 OAuth 2 的设计原理与最佳实践推荐 Justin Richer 的《OAuth 2 in Action》，作者本身就是该协议的设计者。本书在 2019 年也发布了中文版《OAuth 2 实战》。展开评论点赞 - OAuth 2 设计理念分析与实践之八——授权码在系统集成中的应用
在很多系统集成项目中，系统集成商会将各个软件厂商的系统集成到一个门户中供用户统一访问，经常会碰到一种成为免密登录的功能需求。也就是用户登录到主门户后，可以不用再次输入用户名密码就可以使用相同的账号访问到其他子系统。而这个过程就非常契合 OAuth 2 的应用场景。
而抽象一个用户管理与认证中心（IAM，Indentity and Access Management）成为了经典设计，IAM 统一管理用户、角色、权限等信息，并提供用户服务、认证服务、授权服务等能力。所有业务系统涉及系统接入、访问控制、认证授权、用户信息获取等全部经过 IAM。这样，用户得到集中管理，并与业务解耦。
那么，打通各系统间的登录也就不麻烦了。对照 OAuth 2 的角色划分，主门户成为客户端的前台，子系统成为客户端的后台，IAM 是授权服务与受保护资源的统一实体，提供的授权服务用于主门户接入更多子系统，提供的用户信息就是受保护资源，并且对申请获取用户信息的访问提供校验能力。
整个对接流程如下：
1、子系统向 IAM 注册客户端信息，包括客户端编码、名称、登录与登出的主门户重定向地址等，用于校验请求令牌与受保护资源的合法性，IAM 分配客户端标识
2、子系统向主门户注册类似的客户端信息，用于主门户控制登录、登出等访问跳转方向，以及存储向 IAM 申请授权码的必要信息
3、用户登录主门户后，发起对某个子系统的访问，主门户携带子系统的客户端信息向 IAM 申请用户授权，也就是先获取授权码
4、IAM 校验通过后，重定向到请求地址，并携带授权码
5、子系统注册的重定向地址接收到授权码，向 IAM 换取访问令牌
6、IAM 再次校验后，颁发访问令牌给子系统，子系统拥有了访问用户信息的权限
7、子系统使用令牌访问 IAM 获取用户信息，IAM 解析获取登录用户，返回用户信息
8、子系统使用该用户信息作为登录用户，实现主门户到子门户的免密登录跳转展开评论点赞 - OAuth 2 设计理念分析与实践之七——Authorization Code Q & A
Q1：授权码的作用？
A1：OAuth2 的本质也是授权代理，需要保证受保护资源始终归属于资源拥有者，客户端只是拥有者代理不能直接获取访问令牌，需要通过授权码作为中间凭证，授权码也就完成了对用户密码的保护及授权对接
Q2：授权码许可过程中，两次重定向的作用？
A2：第一，OAuth2基于的是http协议，重定向是前端之间的行为，后台驱动前台重定向通用性差又会增加客户端复杂度；第二，第二次重定向提升用户体验（客户端获取授权码附带的回调地址），避免第一次授权跳转重定向（资源拥有者执行授权）后资源拥有者与客户端之间断开连接；第三，避免访问令牌暴露在前端，减少受攻击面
Q3：不要授权码，直接返回 access_token 并重定向是否可行呢？
A3：通过授权码实现三方制约，OAuth2 不能授予客户端权限获取 token，客户端只是授权代理，代理的凭证是授权码（本质还是受保护资源归属于资源拥有者），从而实现一种三方制约——资源拥有者可以放心授权没被滥用、密码等凭据最小授权，受保护资源也可放心客户端是合法请求没有拖库等危险动作、对客户端请求有效监管、控制资源开放能力，客户端也完成了对资源拥有者的合法代理、完成拥有者的诉求、成就代理商生态展开赞过 21 - OAuth 2 设计理念分析与实践之六——Authorization Code Flow
OAuth 2.0 的核心工作流程就是获取令牌与使用令牌，最常用的授权码许可的工作流程如下：
1、资源拥有者委托用户代理，携带重定向地址、客户端标识等信息，向授权服务发起授权申请
2、授权服务在经过请求用户、客户端标识等验证后，携带授权码重定向到指定地址
3、客户端接收到授权码后向授权服务换取令牌，授权码使用一次立即失效
4、拿到令牌后，客户端就可以向受保护资源发起资源申请，受保护服务校验令牌通过后开放资源访问权限展开评论点赞 - OAuth 2 设计理念分析与实践之五——Abstract Protocol Flow
+--------+ +---------------+
| |--(A)- Authorization Request ->| Resource |
| | | Owner |
| |<-(B)-- Authorization Grant ---| |
| | +---------------+
| |
| | +---------------+
| |--(C)-- Authorization Grant -->| Authorization |
| Client | | Server |
| |<-(D)----- Access Token -------| |
| | +---------------+
| |
| | +---------------+
| |--(E)----- Access Token ------>| Resource |
| | | Server |
| |<-(F)--- Protected Resource ---| |
+--------+ +---------------+展开等人赞过 310 - 数字骨灰盒
话说，到现在还买看到聊天训练成很有个性的产品，对话一长总会有点跳脱评论点赞 - 程序猿的运维知识之五——测试把控质量
产品质量不可能独善其身，是由所有组成要素构成的。测试过程的嵌入式设计也是 DevOps 精髓所在——理解测试金字塔，构建测试流水线，达成持续交付，增强测试流水线信心。
测试金字塔是一种隐喻，强调如何对测试分组以及分组对照数量。从下到上依次为单元测试，集成测试与端到端测试。金字塔底部的测试提供快速反馈，随着测试层级上移，测试速度变慢但测试覆盖范围变大。
测试流水线通常会从执行代码检查开始，逐一通过测试金字塔，最后构建制品，经典实现方案是 Jenkins。涉及到的测试基础设施包括 CD 服务器，制品存储，测试服务器，测试流水线服务器，依赖项仓库等。
体验良好的测试流程可以增强研发与运维团队对产品质量的信心，一经失败主动去排查代码异常，而不是第一个想到测试环境出现问题。同时，尽早通过单元测试保障功能健壮，而不是等到端到端测试费尽周折。最终呈现出的是产品质量提升，避免陷入测试覆盖率等虚荣指标中。展开赞过 评论1
