#程序员#

我已经做了很多很多年开发了。
一开始就觉得 架构师 这是我的中级理想。因为有个技术文章说 比尔盖茨最喜欢的title是“微软首席架构师”，当时觉得好吊，自己一定要在5年成长为一个架构师。
所以“架构”这个命题，一直伴随着我工作这些年
我对架构的理解也侧面反映了我的思考和成长。
这里就聊聊我目前理解的架构，分五个层次。
ps 全文可看 公众号 半文说，这里我会讲解一下我的理解

架构是框架
我刚学软件的时候，当时还是SSH和SSM的天下（好像现在也是）。
因为是自学java并且是通过培训班来学习的，所以接触到的名词都是ssh架构和ssm架构。我掌握了之后也一度自信的认为。自己已经掌握了几套架构了。
这个时候对架构的理解，就是一套套”框架“,比如shrio权限管理，spring，springMvc这样的框架。解决某个特定的问题，达到降低代码量，提高研发效率的事情。
当时所有的重点，其实都是围绕各种”技术“来学习的。比如学习缓存类的api：redis，学习全文查找：ES，权限管理，workflow（activity） 等等。
掌握了这些技术的时候，一度觉得自己无敌了。好像很多的问题我都有解决办法。
但是到了具体项目的时候，很快就发现了自己的SB。不过我也比较庆幸，没有沉迷在不同的技术中间件里面不能自拔。

这里在讲一下我的理解，我发现我们特别容易陷入到“技术崇拜”。仿佛用某个高大上的技术手段就能解决复杂的问题。
其实80%的软件开发工作，是处理一系列的业务问题的（我也是业务架构师）。不是写spring框架这样的工作，因为写基础架构和中间件其实人数还是比较少的。
然后，我们总会认为可以用技术来解决问题，比如10万qps，可能RabbitMQ解决不了，然后我们学习了kafkamq，就觉得换个技术框架就行。事情远没有这么简单。
另外，一些技术框架的文档网上都有，自己愿意读源码也能读到。这些现成的内容是无法体现差异性的。
而我们自己的理解，发挥我们自己的主观能动性，才能获得更高的工资。
所以我这里说的内容，是围绕“架构设计”来讲的。

插眼

架构设计有点类似“设计模式”和DDD这些概念和方法。是可以跨语言的。
不管用java还是go，或者不管是金融，支付，电商，这些不同的业务领域，我们都可以复用的。
我继续深入聊一下第一阶段：架构是框架部分。
第一阶段再深入下去，就是理解和学习各种技术模式的部分。
比如
SOA：水平拆分，垂直拆分，rpc框架（dubbo），springcloud，gate这个服务化模式和里面的一系列技术栈。
分布式事务：jta/xa，tcc模式，saga模式。最终一致性概念，强一致性概念，CAP理论等等。
高并发：消息队列，负载均衡，服务器集群等等。
高可用：异地多活，主备切换。
上面每个技术模式，其实也可以研究的很深入，比如支付宝的分布式事务框架xts，是原CTO鲁肃写的。并且也是开源的。
但是大部分人是使用这些框架，去解决一个场景的问题，然后这些框架在具体场景里面形成的经验，就是一些固定的技术模式。
比如分布式事务，tcc下，存在二阶段空回滚和状态型数据更新问题。等等。
但是这些内容，我感觉是可以直接学会的。甚至不需要特别努力。

架构师具体工作是干啥的，

我之前分享经验，和我的一些知识。大家都在骂我，说我是骗人的，卖课骗钱的，真”大佬“不会玩贴吧，”大佬“竟然还关注孙吧等等等。给我喷的啊，私信99+。
所以我准备把我对“架构”这个问题的理解写出来，和大家一起讨论。
如果说我的理解还是“水货”，或者是“骗子”。那也行，可以告诉我哪里有问题。我也可以获得成长。
另外，我也不是什么大佬，就是一个打工人赚工资的。而且在我看来的一些”大佬“。大家也都是正常人。聊天打屁，朋友圈吐槽。没什么不同。
我也在愁，最近崩铁，抽银狼歪了，痛心很久，还不敢说。

支持

架构就是能把项目搞定 给你分人你能搞定

阿里p8吗

我现在理解架构就是 高级开发+项目经理 的组合

都是给老板打工，1. 技术上能提供可靠的可行性分析和设计方案，2. 给项目组成员，提供简单高效的代码复用性质的封装，3. 屏蔽关键的核心代码，降低人员变动带来的商业风险。 就是一个合格的架构师了

架构就像房子的图纸设计，普通程序员就是砌墙砖，这面墙你砌，那面墙他砌，通过连接最后组成一个房子，到底怎么样让房子怎么砌而且安全又方便好住是图纸设计的事。

《架构之道》：架构是分析软件易变性，对软件系统的拆分。目的是顺应业务变化，降低成本。

插眼