卖完后砍单 :doge

把仅有的兴趣作为工作，才是最可悲的。

可以是可以，但是没有人会这样做吧，对服务器压力很大的。
部分静态页面还好，但是所有静态资源都放到 gateway 后面，试想想一个页面几十上百的页面元素，每个元素都要校验，机器会扛不住的。

建议 LZ 还是学一下 CORS 和动静分离策略吧

静态资源为什么要经过 API 网关？ LZ 究竟想解决什么问题？

其实就是“爆兵”还是“攀科技”？反正有人顶着，我选择“攀科技”

@hstk 你说得对，想象力是天生的，人类从一出生就会做梦。
我这里想表达的是，目前的教育，把人教育得更像机器人，甚至把人和机器人放到了生产效率层面上去对比。

我这里不应该说“扼杀”，应该改“扼制”。

或者换一个更简单的角度去看，如果哪天机器人全面代替人类做生产，人还能有什么价值？而这个价值，就是我们现在需要重视的。

绿绿绿（ 666 ）

沙拉查词

其实 LZ 的想问的，是“如何提高自己的想象力”吧。

很感慨，这正是我们最缺乏的，也是我们教育最失败的地方。我们的教育基本都是以“技能习得”为方针设计的，可能是因为国情需要吧。其实历史很有意思的，但是基本都不会被学校和家长重视，以为学历史以后怎么赚钱？这种“技能习得”的学习思想影响了几代人，我们的好奇心，兴趣爱好，早就被扼杀了。

例如在本站我提过的话题《 Go 的编程思想是什么》，有位朋友说了一下语言的发展历史，这个问题就迎刃而解了。

相对于技能，见识多广更重要。

创意源于一个人的阅历，看《 James Cameron's Story of Science Fiction 》中，几乎所有灵光一现的创意，均源于导演的生活和阅历。

惊人的创意其实是把多种元素多种维度的混合物，因此可以推出的结论是，你阅历的维度，生活的多样性，决定了你创意所包含的元素。

意识到这点就不错了。

技术服务于业务的，没有破解密码的需求，也不会出现第一台计算机了。
不懂业务，还谈什么创造，剩下拧螺丝了。

求指点迷津，如何做到月薪不到一万背一万房贷？

三五个开发，先关注业务吧，活不下来也没法谈什么高大上的架构了。
选个 PaaS 平台，LBS，NameService，RDS 什么都有了，专心开发产品好了。

我觉得，不一定是高大上的技术才能凸显架构师的价值的，架构师还有一个很重要的工作，但很多时候被忽略的，就是如何合理地把现实的业务场景，转化为数据模型，以便能用有效的技术手段去实现。

@daijinming 个人对 ServiceMesh 的理解，关键的组件是 sidecar，类似一个上网代理，挟持主机上所有的应用的网络请求，然后通过通过服务路由，发送到其他节点的 sidecar 上，最后由 sidecar 把请求发送到对应的应用上。可以想象一下，不管节点上有没有部署应用，每个节点上的 sidecar 都相互连接，组成一个服务网络。
ServiceMesh 的设计目的就是把服务路由，服务发现，流量控制等本来需要研发实现的东西，下沉作为基础设施来提供。研发应用的时候，就如使用 TCP/IP，DNS 等基础设施一样。
方案搜搜有很多，不过我没有落地的经验。以我目前的了解，现成的非侵入式方案有个比较大的问题，由于 sidecar 是一个代理，应用的请求数据包会经过两次 TCP 堆栈，会造成性能损耗和资源浪费。所以目前我都是在优化微服务研发框架上，把服务发现，服务路由等能力集成到研发框架里面（也就是侵入式）。Java 的如 Spring Cloud，Go 的如 go-micro

软件架构：先根据手上的人力资源和计算资源的类型选择好技术栈吧，然后用现成的或者自己搞一个研发脚手架。
应用架构：无非选择巨石架构，微服务架构，ServiceMesh，更新一点的就是 Service less 了吧。也是根据目前手头上的计算资源和人力资源来选择。如果你的 IT 运维组能力较弱，例如只是虚拟机运维层面的，用巨石架构，扩展的时候用虚拟机复制。总的来说好像还是要根据手头上的人力资源来做决定。当然，良好的软件架构设计，可以方便你日后从巨石架构到微服务架构，或者到 ServiceMesh 的进化。
业务架构：这需要你十分了解你公司的业务了，多跟业务部门去沟通，业务架构没有标准答案的，都是随着业务发展而演变的。业务架构是为了业务部门服务的，方法论例如 DDD （领域驱动设计），这部分我没啥经验，就不多说了。

1. 访问 A 站点，如果有登录态，正常登陆
2. 如果没有登录态，跳转到 SSO 站点登录页，query 带 A 站点回调地址（这时候是 SSO 的站点了）
3. SSO 站点登录页判断是否有 SSO 站点的登录态，如果有，调用 A 站点回调地址，query 带 token。如果没有就输入用户名密码，登录 SSO 站点成功，调用 A 站点回调地址，query 带 token。
4. A 站点回调地址，获取 query 中的 token，后台访问 SSO 站点的 token 验证接口
5. 验证成功，A 站点后台设置 session，记录 SSO 站点提供的用户信息。

你确定你看懂了 CAS ？

CAS 方案的为什么会存在 cookie 跨域获取问题？不对，CAS 方案为什么要跨域获取 cookie ？

看看当年诺记玩手机，玩到最后只剩下玩镜头了的下场

216j，用过三块东芝 P300，3T，一万小时坏了第一块