多研究些架构，少谈些框架（4）-- 架构师是技术的使用者而不是信徒

我承认我是标题党， 为什么要写这篇充满争议的文章？目前架构师这个职位特别火热，程序员的目标都是成为一个令人尊敬的架构师。但是我们真的理解架构师应该做些什么？很多人把架构师和框架师等同起来，认为研究框架多的才是架构师
下面说的情况请勿对号入座。

• 盲目的追新：
  技术人员的喜好往往是什么技术流行就追什么技术。现在的技术发展快，前后端不断涌现各种框架，我们恨不得把这些框架都用在自己的项目里才行，要不然怎么好意思和别人打招呼啊。
  我亲身经历，有个技术人员一定要把原来单元测试框架的xml初始数据改为json，他的原话是”json看的更舒服”，但是改完后，我们的单元测试反而难落地了，原因是原来的单元测试框架有个工具是可以将表中的数据自动生成xml的，而改成json后，我们必须手写json数据了。 他的喜好不包括给大家更好用的工具。
• 按技术站队，以结果反推：
  很多人把手段当成了目的，成为了框架的信徒。用了Java开发，你的设计就一定是面向对象的？用了Spring boot就是微服务了吗？这些荒唐的事情却在技术圈不断发生，技术人员甚至会按照语言、框架形成不同的圈子，各种技术圈互相鄙视，互相踩，真相此时无法越辩越明，反而把技术方向带歪了。

技术要和实际场景结合

架构师也要深入了解掌握技术，但是更多的是了解技术的优劣和使用场景，而不是简单的生搬硬套。以现在流行的微服务架构来说，Netflix使用RESTful接口作为通讯，我们是不是要把公司的用了n年的基于TCP的RPC换成RESTful接口，因为根据Netflix的实践，RESTful可以更好的解耦、更强的伸缩性等优点，还能支持多种语言开发，互通性好。但是我们需要对RESTful彻底的理解清楚：

• RESTful接口不简单是是http+json，Richardson成熟度模型中哪个层级更合适我们的内网API通讯，HATEOAS是否需要？
• RESTful的核心是资源，如何在微服务中抽象资源概念，如何将基于过程的RPC调用平滑的迁移到RESTful上？
• 多语言开发是快，但是后续维护如何找到稳定的Go、Scala、xxx语言程序员来源？
  以上的问题应该是架构师在考虑引入新技术的时候的重点，其中对技术优劣和架构思路是核心