创业 Ruby 企业级架构师培训（实验班）暨 Rails on Cloud 开源 Contributer 招募
目前职业教育兴起，但是 Ruby 相关的培训较少。
一方面，可能目前的 Ruby 程序员成长较为缓慢。回想起我当时从 PHP、ASP 转行为 Ruby 程序员的时候，还是因为市面上当时 MVC 框架，或者说比较好用的框架较少。而现在，随着大厂的推动，Spring Boot 可以说大行其道，go 语言的相关框架也成为了后起之秀，Rails 的优势不再向之前那么明显。
另一方面，虽然国内不缺乏使用 Ruby 较大规模的公司，但是限于影响力等因素，造成了国内、甚至国外关于 Ruby 企业级架构方面的内容较少。
由于职业发展的原因，从前几年开始，逐步转向了 Java 社区。Java 社区围绕着企业级架构有着丰富的解决方案和成功案例。随着微服务概念的兴起，Spring Cloud、Dubbo 等框架得以更好的流行。
近年来随着 Kubernetes 的兴起，围绕着 Kubernetes 又有人提出了 Service Mesh 的概念。与基于 Spring Cloud 微服务架构不同的是，Service Mesh 可以更好的支持企业中语言异构的问题。
当然，无论是社区内外，有很多人质疑 Ruby 不适合做微服务架构。撇开老生常谈的性能问题，微服务架构本身是不依赖于语言的一种企业级软件架构模式，所以我自然认为没有合适不合适的。
早在很多年前，我关注过 Travis CI 的软件架构。我认为 Travis CI 的软件其实可以算上是一种微服务架构了。
- Travis CI Web 负责前端界面；
- Travis Listener 负责通过 Github Hook 触发 Travis 运行队列；
- Travis Scheduler 负责调度 Travis Job；
- Travis Hub 负责更新 Travis 的运行状态和结果，也就是我们通常在运行 Travis CI 时的输出；
- Travis Log 负责日志相关的操作；
当然 Travis CI 还有一些其他的组件，但是显然可以发现，这个优秀的设计其实也 Kubernetes 如出一辙。
既然，Ruby 不适合微服务是一个伪命题的话，那么怎么做好企业级 Ruby 微服务架构设计呢？
企业级的微服务架构，要保证的是高并发、高性能、高可用。
高并发我们可以通过数据库分库分表、分布式事务等方式去解决；
高性能其实和高并发是一类问题，解决了高并发，自然就解决了高性能；
高可用在应用层级是通过多机房备份、熔断、降级、故障监控、分布式跟踪等实现的。
微服务架构可以分为两种，一种是以 Spring Cloud 为代表的的这种不太适合语言异构的解决方案，一种是以 Kubernetes 为代表的，不关心语言的云原生架构。
无论是那种方式，最终在应用层级的的解决方案几乎是一致的。
这里的一致指的是比如通过注册微服务的方式，解决了需要绑定应用 IP 和端口；比如说通过 load balance 解决了高可用、高性能；通过限流、熔断等保障了高可用等等。
虽然实现的手法不一样，但是最终要解决的问题是一致的。
为此，我根据自己的经历，和所学初步拟定了一个培训教程，一方面希望能对大家有所帮助，也希望能对社区有所帮助，另一方面也想探索一下高龄程序员的出路：）
下面是课程大纲和收费，有兴趣的可以找我了解，也可以免费试听。
另有不足之处，希望大家能不吝指教。
================================ 分割线 ==============================
Ruby 企业级微服务架构师培训（108 课时，每课时仅约 30 元~）
收费（前 30 课时不满意可全额退）
套餐一（早鸟价：1699 元）
- Ruby 进阶培训（30 课时）
套餐二（早鸟价：1699 元）
- Rails 高阶（30 课时）
套餐三（早鸟价：1999 元）
- Ruby 进阶培训（30 课时）
- Rails 高阶（30 课时）
- 架构师组织影响力打造（4 课时）
套餐四（早鸟价，2199 元）
- 架构师进阶（40 课时）
套餐五（早鸟价，2699 元）
- Ruby 进阶培训（30 课时）
- Rails 高阶（30 课时）
- 架构师进阶（40 课时）
套餐六（早鸟价，2999 元）
- Ruby 进阶培训（30 课时）
- Rails 高阶（30 课时）
- 架构师进阶（40 课时）
- 架构师组织影响力打造（8 课时）
上课方式为直播，每星期二、四、六晚直播，每次约两课时，每课时 50 分钟。感兴趣的可以和我联系~
为了巩固和应用所学，准备在架构师课程开始后搞一个 Rails on Cloud 的实验项目，参考 Spring Cloud，构建一个 Rails on Cloud 
ruby 做微服务就是个伪命题，根本没有优势。脑子清醒的人都不会这样搞。实际工程不谈性就是耍流氓。ruby 不适合做大规模企业级开发。单兵可以玩玩
lilijreey
回复
首先你可能对微服务不太了解，其次请好好研究 travis CI 的架构，可以说和 Kubernetes 的设计思路如出一辙。
目前只不过是 Java 微服务生态比较健全而已，不要忘了 Rails 是最早的 MVC 框架，启发了后来的 ThinkPHP，Spring MVC 等等。
如果觉得 Ruby 不适合微服务，可以列出来你觉得不适合的一些点，交给大家一起讨论。
lilijreey
回复
ruby 不适合做大规模企业级开发。
其实 ruby 不适合做大规模企业开发的原因是，你很难招到 500 名 rails 开发，github 也不行。
ericguo
回复
之前的团队后端十几个人，语言用到了 clojure/java/erlang/rust/kotlin/ruby，除了开发还有各种分工，比如负责网络，负责存储，负责稳定性，并且还依赖不少内部团队的服务。
500 人的团队，可能本身就不需要那么多的纯开发。
lilijreey
回复
我记得 Effictive Java 还是《重构》那本书里面提到，Java 这类型的语言其实更适合做中间件，或者更底层的。
因为底层的变化少，多费点功夫，多费点时间是值当的。但是业务类型的，其实更适合 Ruby 这种语言，因为变化快，需要的响应快。
现实的条件是很多人只熟练一种语言，所以无论是杀牛，还是切水果只能选择一种。
汇编是世界上最快的语言（之一），为啥没人用来写互联网 APP 呢？说不准可以提升几个数量级呢。
架构的选择，永远是一种折衷的选择。这里包括团队成员的技术组成，技术水平，架构的流行程度，维护水平等等。
简单的说一种语言适合不适合某种场景，未免太不合适。
rocLv
回复
之前看过一个 rails 的微服务视频，大概意思是说，rails 的哲学和微服务有些冲突。rails 就是在单体应用下效率很好。
而且微服务是 java 社区提出的概念，微服务还是在 java 社区比较原汁原味。
另外，针对架构师课程，我认为一些基础的编程思想和编程范式还是挺重要的，更像是思考的方法，而不只是一些前人总结好的经验和模式。我最近看操作系统，分布式，数据库，计算机网络，包括一些前端开发的内容，很多思想都会反复出现而且通用。
从目录上来看，课程里这些内容比较少或者有所缺失。可能也许真正要做到一个合格的架构师，其涉及到的学习内容确实也没办法一门课程就能很完整的涵盖吧。
kevin_isky
回复
如果完全学通了操作系统，这个课程可以忽略啦...
我感觉目前互联网架构都没有超出操作系统里面的涉及的范畴。
比如说缓存，和 GC 对应的内存管理，各种锁等等...
使用 Rails/Ruby 能不能做微服务？能，但是不要使用基于 Java 或 Go 的实现去复刻 Ruby 的微服务。微服务是一种思想，而不是技术实现。
对于技术新人来说，Ruby 不是很好地选择，原因有很多，核心在于学习曲线和就业，Rails 的学习曲线之所以陡峭是因为 Rails 默认你掌握了数据结构、操作系统原理、计算机网络、编译原理等计算机基石知识。
国内几乎没有企业有高质量、大规模的 Ruby 技术团队。基本上都是小团队，而且基本上都是业务开发。业务开发本质上就是 CRUD。
Rails/Ruby Web 开发者 如果仅做业务开发，3-5 年基本上就到了天花板，转型是不可避免的，具体往哪个方向看个人的能力域了。
Ruby 肯定是能做大规模企业级开发的，市值千亿美金的公司也是有的。
还有，我认为大部分使用 Ruby 的企业，不会招聘 Ruby 企业级架构师的。架构是一种需要在实际业务中摸爬滚打练就的能力，不经历过核心业务在高峰事情频频崩溃，就不会感觉到缓存的妙用。
当同时要维护 10+ 个 Rails 应用，同时又要做到随时发布，弹性扩展，Kubernetes 自然会进入你的研究清单。
Ruby 的性能从 Ruby 2.0 开始，依然不是问题了，不过很多人的思维还停留在上古时期。
a112121788
回复
不敢苟同...
有些人道听途说一些概念，就开始妖言惑众了。
我认识的 rubiests 都有比较强的自学能力，当需要的时候，几乎都可以迅速转到下一种语言的生态。
架构的能力一方面是锻炼出来的，但是如果能踩在前人的肩膀上，比自己摸索不知道要强多少倍。
套用武侠小说里面的话：
- 一重境界：手中有语言，心中无语言；
- 二重境界：手中有语言，心中有语言；
- 三重境界：手中无语言，心中也没有语言。
回顾我现在的知识栈，编程语言所占的比例已经很少了。
- 比如说清洁代码、代码重构的能力，几乎是相通的；
- 比如说设计模式的实践，可以说是无语言差异的（当然不同的语言有不同的实现）；
- 比如说对框架的理解，从最早期对 Rails 的云里雾里，到现在可以比较轻松的理解任意语言的流行框架；
- 比如说 redis，楼主提到的缓存等等；
- 比如说数据库优化的、设计等等
- 比如说消息中间件的应用；
- 比如说推荐系统的搭建、分布式事务以及追踪；
- 比如说应用性能优化、服务器性能优化等等；
- 再到企业架构设计的原则，企业软件架构的模型等等；
ruby 社区里面不乏一些对其他语言理解非常深刻的大牛，他们可以从语言的设计角度去理解内存回收，编译原理等等， 也不乏一些在操作系统层面理解非常深刻的大牛，
如果只是工作了 3-5 年，还纠结于语言也许情有可原；如果工作了很多年以后，仍然停留在语言的层面，那么确实需要提升一下自己的境界了。
即使停留在语言层面，也是分级别的，比如是应用，业务开发，还是阅读源码，或者底层 虚拟机优化。
境界的提升不止技术能力，产品、业务、市场都是做 Ruby 开发的需要提升的点，当然还有很多。
编程语言，哪个适合就用哪个。有时候哪个顺手就用哪个。这样不一定对，但这是我有这样选的权利。
牛人肯定有，但是牛人很难把自己的成长经历复刻到新人身上。
其实我希望市面上有更多初级、中级、高级等 Ruby 相关的课程出来，但是存活的几率太低了。
如果有 Ruby 相关的企业能联动就好了。新招一个其他语言的转做 Ruby 的初级开发者，企业的内部培训成本也在 2 万+。
rocLv
回复
目前只不过是 Java 微服务生态比较健全而已，不要忘了 Rails 是最早的 MVC 框架，启发了后来的 ThinkPHP，Spring MVC 等等。
这就夸张了哈，把 Struts,WebWork 放哪了。
rocLv
回复
首先呢，我是支持你这么做的，毕竟也算是个人贡献。而且我也不打算能说服你。你的汇编语言的观点是站不住脚的。因为你不用一个极限的例子去证明普遍的问题。我就问你一个问题，你们做过的系统最多部署在多少太机器上。我想可能十几台都没有。这就谈不上什么企业级架构。因为这种规模下 90% 的技术都能解决问题，你说 ruby 好也只是自卖自夸罢了。如果你们的系统跑在几百台，几千条，几万台机器上你就会发现压缩成本是一个永恒的目标，ruby 根本没有生存空间。而且你也说了企业级的微服务架构，要保证的是高并发、高性能、高可用。 这几点一直都是 ruby 的鸡肋。C++,java,go, node,rust,erlang 那个不吊打你啊。
lilijreey
回复
我现在的公司，Ruby 服务线上的 CPU 很早就上千了。出了很多问题，在我的印象里，没有一个是由语言引起的。
上份工作，整个后端服务（这个服务是企业级的，虽然我不知道企业级是怎么定义的 
），CPU 用了大约有 300 到 500 吧，语言有 Clojure/Erlang/Java/Rust。
1000 核的 CPU 在阿里云上，一年大约 100w，大约是 2 ～ 3 个初级程序员的钱。
Erlang/Java/Rust 的服务都做过或者看过别人做过一些优化，大多数问题，还是跟架构，实现有关。
还遇到过很多有趣的事情，比如 Erlang 并发好，结果流量一上来，他第一个躺尸。Rust 不是内存安全吗，一部署，丫内存就涨涨涨。倒是 Java 保持了他一贯的水准，经常内存泄漏。
我们有个服务原来是 Erlang 的，后来用 Rust 重写了。Rust 一样要解决性能和扩展性的问题。Erlang 性能是差一点，但目前的流量，翻十倍，Erlang 一样扛的住。翻一百倍，Rust 没准也会躺。Rust 和 Erlang 比起来，确实能省些机器钱，但太折腾了。Rust 是快，但网络延迟考虑进去的话，也就优势不大了。
高并发、高性能、高可用
web 开发，瓶颈在 IO。不过 Ruby 并发确实不咋样。不过，还是那句话，多数的时候，问题没在语言上。
高可用上，ruby 积累的很少，甚至可以说还没有这方面的意识，但多数手段，跟语言也是无关的。
