江苏龙网

  1. 首页 > 人文 > >

没有架构师的命，却得了架构师的病( 二 )


这算不算架构中的一部分 ， 根据不同的应用需要 ， 去设计不同的策略 ， 同时把这些场景规范化 ， 成为一整个团队都要去遵循的标准?
我不知道 ， 我只知道 ， 能 Hold 住团队里所有人的那个人 ， 技术一定非常 NB ， 团队里的每一个人 ， 都会质疑 ， 如果你 Hold 不住全场 ， 怎么能推行下去?
当时近 30 的技术团队里 ， 每一个都是神一样的存在啊 ， 谁能 Hold 住 30 多个神 。
而且 ， 原来不应该把所有的代码放到一个 Web 里 ， 原来分布式是这么回事儿 ， 原来一个系统 ， 是由多个子系统构成的 ， 原来还要分层 ， 原来封装和抽象是这么个意思 。
Web 层是一层 ， 通常可以通过 LVS 部署两台到三台 ， 或者是更多的 ， Service 一层用来处理业务逻辑 ， 缓存层用来扛并发 ， 一定要藏在 Service 里面 。
Controller 调用 Service 的时候 ， 并不需要知道数据到底从哪来的 ， 每一个 Service 使用什么样的缓存策略 ， 完全不需要 Controller 层知道 。
对于大型应用来讲 ， MySQL 只能用做是持久化 ， MySQL 的单条访问速度并不查 ， 只是在并发能力太差 ， 扛不住 。 但是 ， 有可能数据量过亿啊?
过亿怎么办?是用分库 ， 还是分表?读写分离要不要做?一台服务挂一台数据库 ， 哪些数据库应该放在一个实例里 ， 哪些应该单独拆出去?每台服务器的配置是什么?
我大概知道一点点 ， 架构师要做哪些事情 ， 他就是要把这些大的骨架定好 ， 然后我们去填充里面的内容 。 如果骨架定歪了 ， 其余团队必然跟着歪 。
这时候有了一系列的问题 ， 第一个 ， Controller 和 Service 之间 ， Service 和 Service 之间 ， 应该通过什么调用?
RMI ， 这是惟一的选择 。 用 Thrift ， 或者是 ProtocolBuffer ， 或者是 Rest 实现的 RPC?
这是架构师要考虑的事情 ， 如果是用 RMI ， 我们是要自己实现 ， 还是要找找是否有好用的开源的框架 ， 在其他的系统里被证明了是有用的?
大神们花了两周的时间 ， 对当时流行的开源框架过了一遍 ， 最终选定了 Tuscany ， 到现在我都觉得设计精美 ， 完暴 Dubbo 的东西 ， 真的是一点都不想切到 Dubbo 上去 ， 毕竟“曾经沧海难为水 ， 除却巫山不是云” 。
直到最近几年微服务兴起的时候 ， 我还是同样的目瞪口呆 ， 这跟 2009 年搜狐当时做白社会的架构比起来 ， 优势倒底在哪里?
差别好像没有那么大啊 ， 而且 Tuscany 实现的更完美 ， 只是使用的时候要有更强的约束 ， 因为 Tuscany 太强大了 ， 强大到有一点点重 ， 必须要做简化 。
而且 ， Tuscany 的开发团队不怎么维护了 ， 白社会当时做的东西 ， 还是大神花了两周的业余时间写了一个 Scallop ， 增加了 Tuscany 的负载均衡的功能 。
但是 ， 到底用什么 ， 不用什么呢?除了 Tuscany ， 还讨论过要不要用 Hadoop ， 要不要用 ActiveMQ ， 要不要用 Erlang 。
每一个技术框架的选择 ， 都经过讨论 ， 验证 ， 测试 ， 最终在全团队里推行 。
没有架构师的命，却得了架构师的病
本文插图
这是否也是架构师的职责?这个架构师太厉害了 ， 他需要从前到后都要懂 ， 他需要制定关键的技术细节 ， 他需要给出最佳实践 ， 他需要了解业界所有流行的解决方案 。
他需要去猜测 Facebook 怎么解决问题的 ， Twitter 怎么解决问题的 ， Google 怎么解决问题的 ， 这些解决方案可不可以拿过来 ， 也同样适用于我们自己的场景 。
他需要精通分布式 ， Nginx 或者是 F5 ， 微服务 ， 缓存 ， 持久化 ， 消息队列 ， 他需要熟悉所有这些技术细节里的最常用的解决方案 ， 不能有遗漏 ， 也不可以过度设计 。
他决定的不是他一个人喜欢的风格 ， 他决定的就是整个团队 ， 在项目死亡之前都必须遵循的规范 ， 现在的团队成员 ， 和未来的团队成员 ， 都必须遵循的体系 ， 而且 ， 如果在未来 ， 这些架构体系有不合理的地方 ， 那就麻烦大了 。


推荐阅读


上一篇：创业板|2020.08.23周末重要消息汇总

下一篇：大众软件海韵发布8Pin转12Pin供电接口