可以加我微信 rocwar

简单用了一下，mqtt 的工具还比较多，也有挺多可视化工具。我感觉和消息队列的有点像。

无论是 http，rpc，mqtt 这些，其实编程的时候感觉不是特别的明显。

主要可以了解一下具体的特性和使用场景，以及相关生态

嗯，你说的对

付费连更了，只有一个付款

@363676727 https://ruby-china.org/topics/41519 准备开个课程了，可以了解一下。公众号名字改为 云原生架构之美 了

@huacnlee 联系方式已经添加了，重新排版了一下。您有时间看看？

昨天正好看到了 gserver 中的线程池的实现，貌似虽然简单不过健壮性更好一些。

有道理，我先安排上

心中一直有这样一个梦想，免费培养一万名 Ruby/Rails 程序员

不敢苟同...

有些人道听途说一些概念，就开始妖言惑众了。

我认识的 rubiests 都有比较强的自学能力，当需要的时候，几乎都可以迅速转到下一种语言的生态。

架构的能力一方面是锻炼出来的，但是如果能踩在前人的肩膀上，比自己摸索不知道要强多少倍。

套用武侠小说里面的话：

• 一重境界：手中有语言，心中无语言；
• 二重境界：手中有语言，心中有语言；
• 三重境界：手中无语言，心中也没有语言。

回顾我现在的知识栈，编程语言所占的比例已经很少了。

• 比如说清洁代码、代码重构的能力，几乎是相通的；
• 比如说设计模式的实践，可以说是无语言差异的（当然不同的语言有不同的实现）；
• 比如说对框架的理解，从最早期对 Rails 的云里雾里，到现在可以比较轻松的理解任意语言的流行框架；
• 比如说 redis，楼主提到的缓存等等；
• 比如说数据库优化的、设计等等
• 比如说消息中间件的应用；
• 比如说推荐系统的搭建、分布式事务以及追踪；
• 比如说应用性能优化、服务器性能优化等等；
• 再到企业架构设计的原则，企业软件架构的模型等等；

ruby 社区里面不乏一些对其他语言理解非常深刻的大牛，他们可以从语言的设计角度去理解内存回收，编译原理等等， 也不乏一些在操作系统层面理解非常深刻的大牛，

如果只是工作了 3-5 年，还纠结于语言也许情有可原；如果工作了很多年以后，仍然停留在语言的层面，那么确实需要提升一下自己的境界了。

如果完全学通了操作系统，这个课程可以忽略啦...

我感觉目前互联网架构都没有超出操作系统里面的涉及的范畴。

比如说缓存，和 GC 对应的内存管理，各种锁等等...

感谢建议~ 后期有这个打算，所以课程价钱就开的很低

感兴趣就来吧，这其实也就是一个部分的课程。

我记得 Effictive Java 还是《重构》那本书里面提到，Java 这类型的语言其实更适合做中间件，或者更底层的。

因为底层的变化少，多费点功夫，多费点时间是值当的。但是业务类型的，其实更适合 Ruby 这种语言，因为变化快，需要的响应快。

现实的条件是很多人只熟练一种语言，所以无论是杀牛，还是切水果只能选择一种。

汇编是世界上最快的语言（之一），为啥没人用来写互联网 APP 呢？说不准可以提升几个数量级呢。

架构的选择，永远是一种折衷的选择。这里包括团队成员的技术组成，技术水平，架构的流行程度，维护水平等等。

简单的说一种语言适合不适合某种场景，未免太不合适。

这个课程虽然说前 30 课时才能退，但是对于一些非常不认可的，可以随时退

首先你可能对微服务不太了解，其次请好好研究 travis CI 的架构，可以说和 Kubernetes 的设计思路如出一辙。

目前只不过是 Java 微服务生态比较健全而已，不要忘了 Rails 是最早的 MVC 框架，启发了后来的 ThinkPHP，Spring MVC 等等。

如果觉得 Ruby 不适合微服务，可以列出来你觉得不适合的一些点，交给大家一起讨论。

算逐步进阶吧~ 架构方面我觉得接触的越早越好，不一定会用，但是至少别人讨论的时候，可以参与进来

主要就是针对刚学习 ruby 和 rails 的人...

大佬怎么算的

processon

微服务不挑语言，生态挑

一部分疑问你自己回答了，另一部分答案是并不是所有的注册中心都是这种实践的。

说耦合也正确，框架的目的是让开发更聚焦业务本身。适当的耦合比不耦合更好

第一种方法：使用通配符证书，同一个证书支持所有子域名。 第二种方法：可以为 www 子域名再申请个证书，然后 www 的访问 redirect 到根域名

楼主应该是有基础的

典型的钱少要求多

这个看你怎么理解。

很多人是基于“我不会，你说的那些有啥用”而说出来的一大堆理由。

最早大家喜欢讨论的是“程序员懂英语有没有用？”，后来有段时间，大家有喜欢讨论“程序员需要懂算法吗？”，

讨论这些没有必要，自己会了，不就知道有没有用？

不会，讨论这些有什么意义？反正说了也不懂。

应该是 Martin Fowler 的企业应用架构模式里提到过，语言的分层选择。

对于底层的代码，由于后期变动少，对性能要求高，建议用中高级语言，如 C，java 这些。

对于近业务层的代码，建议使用语言表达更丰富，开发效率更高的语言，如 Ruby 之类。

这是我看了所有关于语言讨论里最认可的。

@ccmywish 可以和清华镜像提一下，看他们愿意不

出版社觉得 Ruby 的书，销量太差了。不愿意出。目前在微信公众号上更新，可以搜一下 百万架构师之道