• 其实如果仅仅是这个程度我想也不必非要用 devise,我是更看中其他扩展性,比如和 doorkeeper 集成,再比如 devise 有一些 小生态 都是我觉得近期很可能用到的功能,如 邀请制 再如 双重认证

    其中 devise + doorkeeper + openid-connect 是我实实在在用过的,使用的库是 这个。整体来说并不好用,很多 oidc 的功能当时并没有,学习成本较高,自己需要做一些 tricky 的事情。但是,确实工作,并且总的来说也降低了这部分的研发成本。但是那次项目并不是一个成熟的项目,还是很担心以上同学提到的在真正生产环境还是会遇到问题。

  • 嗯,这也算一个很有说服力的例子,谢谢,我再好好考虑考虑

  • dump 模板就是自己实现一个界面吧?这个似乎逃不过,我可以接受。至于你说的 “修改功能时要了解它非常复杂的内部构造” 不知可否举一两个例子呢,谢谢了。

  • 本来是想回 ruby-china 问问题,结果看到这篇译文,因为自己也在做架构方面的事情,仔仔细细看完了。发表一点自己粗浅的看法。

    首先我个人对他们导致架构变更成微服务的理由不太认同。

    中心队列失败就要用微服务顺理成章?

    从故事的开始讲到因为中心队列因为个别服务有问题就要换成微服务似乎很自然,可是这哪儿顺利成章了啊...为什么我首先想到的是 "失败队列" 呢?关键词搜索 失败队列 一大堆实践啊。为啥队列有问题就要上微服务啊?我不明白啊?并且最后绕了一圈不还是在单体下解决了这个问题了吗?一开始想到这个办法是不是就不这么费劲了啊?

    个别测试的失败常常会导致整个项目测试无法跑通也是换微服务的理由?

    一开始没明白这是什么意思,看到后面讲用 yakbak 突然就明白了,哦,原来他们在测试的时候去调了真实的目的地啊,哇哈哈,那看来他们从来不知道什么叫 mock server 啊,再去用 mock server 关键词搜索,又是一大堆东西。

    所以我的感受就是他们被外部的营销影像了,一遇到问题没有做充分的调研就跑去微服务了...

    先讲一个做机器学习方面的朋友发的一个朋友圈,说有人跑过来说他觉得深度学习不好,用了效果反而变差了,然后他就直接怼回去,”不是深度学习不好,是你的模型写的不好"。在这里我觉得也是类似的情况,首先微服务本身就没有非常非常清晰的定义,更不是看了五分钟微服务教学就可以用了。

    我觉得他们这么碎的服务硬要一个个拆分成微服务本身就不妥了,再说说他们用微服务的时候我觉得哪里不妥。

    失去独立性的微服务确实很难受

    我个人感觉微服务一个核心优势在于独立:不关心用的什么语言,什么处理机制,你爱用什么用什么,你爱依赖什么依赖什么,我都不用管,只要我依赖你的接口正常我就满意。而他们的微服务却全部依赖一个中心库...而且这个中心库还要为了支持各个微服务而不断的做变化...然后各个微服务还必须要(起码他们是希望)及时更新这个中心库。这很明显是一个重大的失误。试想一下,如果你用的 rails 每天都更新,而且建议你每天都要跟最新版本,你还用不用它...真正的做法应该是只提供一个基础功能的库提供给所有微服务,然后微服务在自己特定的需求下自行调整,一定程度的重复都是没关系的。这样做的目的就是保证通用库要做到最大化的稳定,不到万不得已不需要做任何更新,这样才不会给各个微服务添麻烦。

    而且更可悲的是我感觉这个中心库把很多微服务该干的事情都干了,那你不就是搞了 100+ 贫血服务吗?搜索贫血模型,又是一堆信息...

    所有我觉得吧,这个锅其实不该微服务来背,每个大的架构有其使用场景,然后一旦系统出了问题不要动不动就换架构,就像机器学习领域很多人就算不用深度学习人家模型效果也很好,当然,用了机器学习可能效果尼玛更好了,这。很多时候不是深度学习的问题。

  • 话说第一张中间那个应该是个女孩吧....

  • hyper.sh 是国内的哦?

  • 很有用,非常感谢

  • 那么问题来了,作为一个大陆公民是不是还是不能使用呢?

  • 到 18:30 离开公司。18:30 到家

    公司和家里的有多近 😂

  • 这是一个非常有趣的 Gem at 2017年07月04日

    话说 jav 不是付费么....