什么是架构师，架构师要做什么事情，为什么Java的领域里会更注重架构师？

　　什么是架构师，架构师要做什么事情，为什么Java的领域里会更注重架构师？

　　什么是架构师，架构师应该做什么，为什么在Java领域更关注架构师？

　　很久以前，我根本不了解架构的概念。依稀记得建筑这个词来自建筑领域。

　　对于我这种没写过几行代码的人，瞬间有种“不明不白暴力”的崇拜感。

　　架构，感觉好强大。从名字上看，似乎是设计了根源、底层、最核心的东西的人。

　　架构师一定很NB。我什么时候可以成为一名建筑师？

　　后来了解了一点代码，写了增删改查。我无法理解建筑的概念。不就是Sql语句吗？显然DBA更厉害，做各种慢Sql优化，所有的Sql都要经过DBA审计，DBA很关心Mysql或者Oracle的性能，熟悉业务的开发者经常能写上几万条SQL语句行。

　　我看到这些脑袋要爆炸了，好吗？

　　那么，结构是什么？整个系统只有一个WEB，Spring MVC+Spring+Hibernate包办一切，开始做需求分析。其实就是设计表结构而已。剩下的就是检查、修改、删除、删除。

　　直到有一天，我知道了一个词，缓存。

　　缓存东西。很早以前在学习各种基础课的时候，对一级缓存、二级缓存等都略知一二。我好像对LRU有点了解，但是在系统中，cache算是什么？

　　在公司里，架构师画了一张图，告诉我们这台机器上有一个Memcache，但我们没看懂。他只说明这个Memcache是​​一个缓存。

　　我的第一个困惑是，所有请求都必须再次转发到另一台机器才能获取数据。单个请求可能没什么大不了的。每天有成千上万的请求。中间的损失不是很大，为什么不把Memcache放在本地机器上？

　　他没有解释，他只是告诉我它并不大，Memcache只是需要放在另一台机器上。

　　当时不知道内网和外网的区别，也不知道访问Memcache需要多少MS，不明白。把Memcache和业务层放在同一台机器上，或者单独打开。有什么区别。

　　但是这个问题一直困扰着我。简单来说，这其实是架构师需要做的一点点萌芽。在一个系统中，如果拆解了很多模块，应该部署在哪些机器上？架构师会解决这些问题。

　　后来到了搜狐，突然发现之前学过的东西，直接在搜狐的技术高手面前轰轰烈烈。

　　什么是负载均衡？什么是热备？

　　渗透数据库是什么意思？为什么我从数据库中取一个值，而数据库中却没有值，这种空数据请求会跨DB？我应该单独缓存这些 Null 请求吗？

　　使用本地缓存作为一级缓存，使用Memcache作为二级缓存？

　　“对于缓存来说，最关键的设计就是失效策略是什么。”大神平静地看着我。

　　我很害怕。感觉设计失效策略不容易。

　　不同的应用场景对缓存和实时性的要求不同。该列表每天更新一次，只需每晚生成一次。是在后台更新的，但是需要注意的是必须直接生成，直接切换。当前端用户无法访问时，重新生成。

　　对于名称之类的东西，用户必须在更改后立即更新缓存，包括本地缓存和远程缓存。

　　这是架构的一部分吗？根据不同的应用需求，设计不同的策略，同时将这些场景标准化，成为整个团队必须遵循的标准？

　　我不知道，我只知道能hold住团队所有人的人一定是非常NB的技术。团队中的每个人都会质疑，如果你不能保持观众，你怎么继续？

　　在当时近30个技术团队中，每一个都是神一样的存在。谁能容纳30多个神。

　　此外，事实证明，不应将所有代码都放在一个 WEB 中。事实证明它是分布式的。事实证明，一个系统是由多个子系统组成的。原来是分层的。原来的包装和抽象就是这样一个意思。

　　WEB层是一层，一般两到三层以上可以通过LVS部署。 Service层用于处理业务逻辑，缓存层用于承载并发。它必须隐藏在 Service 中，Controller 调用 Service 时，不需要知道数据来自哪里，以及每个 Service 使用的缓存策略。 Controller层不用知道，持久化，是的，对于大型应用，Mysql只能用做持久化。 Mysql的单次访问速度没查，但是并发性太差撑不住了。但是，数据量有可能超过1亿吗？

　　超过1亿怎么办？你应该使用子数据库还是子表？我需要做读写分离吗？一个数据库链接到一项服务。哪些数据库应该放在一个实例中，哪些应该单独删除？每个服务器的配置是什么？

　　我可能对架构师必须做什么有所了解。他就是把这些大骨架架起来，然后我们去填内容。如果骨架歪了，其他人就难免跟风。

　　此时有一系列问题。一、Controller和Service之间、Service和Service之间应该叫什么？

　　RMI，这是唯一的选择。使用thrift，或者ProtocolBuffer，或者Rest实现的RPC？

　　这是架构师需要考虑的事情。如果我们使用 RMI，我们应该自己实现它，还是应该找到一个有用的开源框架，并在其他系统中被证明是有用的？

　　大神们用了两周的时间把当时流行的开源框架都看完了，最终选择了Tuscany。直到现在，我觉得设计的很精致，Dubbo的东西是完全够不着的。我真的一点都不想剪。达博上去，毕竟“曾经的海难，但巫山不是云。”

　　直到这几年微服务的出现，我还是傻眼了。与搜狐2009年的白人社会结构相比，优势在哪里？差别好像没那么大，而且Tuscany的实现比较完善，但是在使用的时候有比较强的约束，因为Tuscany太强大了~有点重，必须简化一下，Tuscany开发团队不怎么保养呢？白会当时做的就是大神利用业余时间用两周的时间写了一个扇贝，增加了托斯卡纳的负载均衡功能。

　　但是，它是使用的还是不需要的？除了Tuscany，我还讨论了是使用Hadoop、ActiveMQ还是Erlang。

　　每个技术框架的选择都经过讨论、验证、测试，并最终在整个团队中实施。

　　这也是架构师的责任吗？这个架构师太厉害了。他需要从头到尾地理解。他需要制定关键的技术细节。他需要提供最佳实践。他需要了解行业中所有流行的解决方案。他需要猜测 Facebook 如何解决这个问题。是的，推特怎么解决的，谷歌怎么解决的，能不能带过来，也适用于我们自己的场景。

　　他需要精通分布式、Nginx 或 F5、微服务、缓存、持久化、消息队列，他需要熟悉所有这些技术细节中最常用的解决方案，不能有遗漏，也不能超过-设计。他决定的不是他一个人喜欢的风格。他决定的是整个团队，项目死前必须遵循的规范，现在的团队成员和未来的团队成员必须遵循的体系，如果以后这些架构体系不合理，那就麻烦大了.

　　像这样的架构师还有一个主要任务是修复开源软件中的错误。

　　很久以前，我一直错误地认为开源软件是一个很强大很NB的东西。我一直认为它是完美的。久而久之，才明白所谓的完美，是用血泪塑造出来的。来了。

　　如果没有使用各种验证、环境和测试，很难达到稳定的在线标准。即使在线，也可能会出现之前完全没有预料到的问题。

　　但是，如果你选择这个框架，如果出现问题，谁来解决？

　　架构师，他需要打开源代码，了解这些开源框架的思想，然后寻找可能存在的问题，然后修复他。

　　我一直觉得能看懂别人写的代码的人就是神。

　　有段时间去看了个heritrix，神​​清气爽，各种继承，各种抽象类，连续三天都想死了，再坚定一点就没有了'我也不想死不允许其他人在项目中使用继承确定。

　　但是Heritrix从外面看起来很不错，他的爬取策略也很NB，使用的分布式爬取方案非常轻量级。可我，真的不想再读了。我当时看不懂，因为资料太少。

　　那么，架构师是否需要了解所有这些源代码？还是说他必须有阅读源代码的能力，而且他必须阅读源代码并优化它？这可能比提前知道源代码更神奇。

　　因为有时间要求。简单地说，他需要在有效的时间内了解所有潜在的事物。说实话，同事笑我的时候，我还没有完全看懂TCP。详细解释/IP协议的时候，我真的无话可说。

　　我对底层的东西了解不多，但架构师不同。

　　有了这些，你能称得上建筑师吗？

　　架构师需要了解业务吗？可不可以天天看技术，写底层框架（比如我们搜狐用的DAL和数据访问层，简直就是神器用起来了）。

　　没有不了解业务的架构师。所有架构都取决于业务。所有架构师还必须编写业务代码，并且不要在实际项目中使用他们设计的内容。恐怕他们自己也不会知道这种架构设计的合理性。

　　在一家团购公司上市之前，他们的 CTO 向我展示了他们的架构图。在给我展示之前，所有的技术术语都是一样的，但是当我仔细查看架构图时，我感到困惑。 . . .

　　为什么要在Controller层调用Memcache？不应该放在Service层吗？

　　你怎么说Serivce维护的数据也可能被其他Service改变？每个服务必须独立于数据运行。除本服务外，其他服务均不得直接更改数据库。

　　另外，为什么Service被拆分了，而DB却没有拆分？在这种情况下，受压的 DB 将拖过整个站。

　　看到架构图后，我觉得我的认知被打破了。我能做到这一点。原来，同样的、相似的技术选择，也能做出这么难的事情？

　　就在我以为这实际上几乎是所有建筑师的时候。

　　最近一段时间，突然发现一个问题。

　　为什么有些人写的代码如此糟糕？很多写得很烂的代码根本没有灵活性，也没有标准，完全是压倒性的。

　　为什么有些人根本不知道如何抽象，也不知道如何将它们积累成公共组件？为什么他们改变一个问题，这通常会导致更多的问题？

　　为什么他们代码中的实现计划让人看了之后就讨厌，而且想要改，根本改不了。毕竟，正常工作的代码就是好代码？

　　很大程度上是因为很多程序员不了解代码的可扩展性，不会为以后编程。

　　您如何称呼面向未来的编程？

　　优秀的工程师在听到这些需求时，可以根据自己的业务能力判断哪些需求可能会发生变化，哪些不太可能发生变化。

　　对于这些变化的内容，在写的过程中，不会很难写，反复确认不太可能变化的需求会更简单，防止过度设计带来的复杂性。

　　简单的说，当他拿到需求的时候，不是简单的考虑如何实现需求，还要考虑自己设计的架构和可扩展性。在他眼里，他看到的要求都会受到影响。分解，拆分，然后将您自己的技术方案一一分解和分发。

　　完成设计后，他会清楚地知道他设计的系统中支持哪些更改。您可以随心所欲地更改它。我只需要改变一个非常简单的内容，你绝对不能改变。要改变，我必须花很多钱，尤其是在数据已经连线的情况下。

　　并且我会用我自己的架构系统和PM沟通并说清楚。

　　支持什么样的更改？短信通道可能会发生变化，可能有很多地方可以调用短信通道，所以我必须将短信通道抽象出来，封装在一个公共接口中。如果我需要更改短信通道，我可能只需要更改一个配置文件。国家队。

　　那么不支持什么样的更改？我不需要在不停机的情况下更改短信通道的功能，除非你提前在后台系统中配置它，或者有明确的需要，我做了这样的事情。往往前期用不到。

　　为什么？

　　在创业初期，经常使用短信渠道进行用户注册。一旦出现问题，就是生死攸关的问题。必须有备份。运营商一怒之下屏蔽你的频道是很常见的。

　　在创业初期，重启服务往往不是那么严重。

　　那么，这些技能是否也应该收录在架构师的职责中？

　　建筑师必须从一开始就考虑选择。从语言做起，从业务做起，必须熟悉和了解该领域的开源框架。他们必须能够解决难题，了解安全性，知道如何备份，并学会面对未来的编程还需要什么？

　　DevOPS 也是必需的。

　　持续集成时代，服务器规模越来越大，云服务器时代，异地存储，冗余灾难，全球化越来越快的时代。

　　运维的重要性已经达到了非常核心的程度。弹性伸缩、自动扩展、灰度发布等概念和需求都在影响着架构师概念的定义。

　　如果说以前的架构师，他们更多是在系统开发之前，现在他们在系统上线后越来越偏。

　　还包括数据分析、日志分析等。顺便说一下，Nosql DB、实时搜索、知识库、算法等都没有提到。

　　每一个领域都在细分，每一个概念都在深化。

　　简单来说，建筑师确实与语言无关，但肯定与语言有关。

　　你可以说建筑师在做选择，但他们只能做选择，他们当然不能成为建筑师。

　　Java 更需要架构师，因为它是各种开源框架。如果对这些框架没有清楚的了解，你很难做出好的选择。一旦架构确定下来，实际业务人员的开发就会简单很多。

　　说到这里，我说清楚什么是建筑师了吗？

　　而你，你还想成为一名建筑师吗。

　　无论如何，当我说我是一名建筑师时，我为自己感到羞耻。我知道我离架构师的能力还很远。