软件架构师“从入门到入土”

什么是架构？

软件总体的结构,软件的设计图。

为什么要出现架构？

一个软件太大了，一个人的心力很难完全构建出来，以至于需要很长时间或者多人合作开发。一个人的话，一开始自己对自己要做出来的东西可能会有一个清楚的认识，但时间长了就会忘记，就需要一个设计图来进行对照。但一群人的话，需要都遵循这个整体的结构，彼此之间通过约定好的接口来进行通讯，就像分布式开发。

架构解决谁的问题？

架构解决用户的问题。不同的架构有不同的侧重点，比如需要的同时支持几万个用户在线的就可能需要redis数据库，单纯的mysql是不现实的。用户心里面有一个模型，说出来的可能和他心里想的模型不一致，这就需要架构师设身处地地站在用户的层面思考，针对用户的真正需求设计架构。

---

必备各种流行技术

知道所有的主流框架，技术的原理和用途；
比如：
  负载均衡是什么？热备又是什么？穿透DB是什么意思？怎么我取数据库里取一个值，数据库里没有，这种空数据的请求会把DB打跨？为什么还要把这些为Null的请求单独缓存起来？本地缓存做为一级缓存，Memcache做二级缓存？“对缓存来说，最关键的设计就在于失效策略是什么。”不同的应用场景，对于缓存的要求不一样，对实时性的要求也不一样。榜单这种一天更新一次的，每天晚上定时生成一次就好了。后台更新，但是要注意，一定要直接生成，直接切换，不能让前端用户访问的时候，再去生成。对于名字这种东西，用户改完之后，必须立刻更新缓存，包括本地缓存和远程缓存。
  而且，原来不应该把所有的代码放到一个WEB里，原来分布式是这么回事儿，原来一个系统，是由多个子系统构成的，原来还要分层，原来封装和抽象是这么个意思。WEB层是一层，通常可以通过LVS部署两台到三台，或者是更多的，Service一层用来处理业务逻辑，缓存层用来扛并发，一定要藏在Service里面，Controller调用Service的时候，并不需要知道，数据倒底从哪来的，每一个Service使用什么样的缓存策略，完全不需要Controller层知道，持久化，对，对于大型应用来讲，Mysql只能用做是持久化，Mysql的单条访问速度并不查，只是在并发能力太差，扛不住。但是，有可能数据量过亿啊？过亿怎么办？是用分库，还是分表？读写分离要不要做？一台服务挂一台数据库，哪些数据库应该放在一个实例里，哪些应该单独拆出去？每台服务器的配置是什么？
  架构师需要从前到后都要懂，他需要制定关键的技术细节，他需要给出最佳实践，他需要了解业界所有流行的解决方案，他需要去猜测Facebook怎么解决问题的，Twitter怎么解决问题的，Google怎么解决问题的，这些解决方案可不可以拿过来，也同样适用于我们自己的场景。他需要精通分布式，Nginx或者是F5，微服务，缓存，持久化，消息队列，他需要熟悉所有这些技术细节里的最常用的解决方案，不能有遗漏，也不可以过度设计，他决定的不是他一个人喜欢的风格，他决定的就是整个团队，在项目死亡之前都必须遵循的规范，现在的团队成员，和未来的团队成员，都必须遵循的体系，而且，如果在未来，这些架构体系有不合理的地方，那就麻烦大了。
```#### 什么是架构？

软件总体的结构,软件的**设计图**。

 

#### 为什么要出现架构？

一个**软件太大了**，一个人的心力很难完全构建出来，以至于需要很长时间或者多人合作开发。一个人的话，一开始自己对自己要做出来的东西可能会有一个清楚的认识，但时间长了就会忘记，就需要一个设计图来进行对照。但一群人的话，需要都遵循这个整体的结构，彼此之间通过约定好的接口来进行通讯，就像分布式开发。

 

#### 架构解决谁的问题？

架构解决用户的问题。**不同的架构有不同的侧重点**，比如需要的同时支持几万个用户在线的就可能需要redis数据库，单纯的mysql是不现实的。用户心里面有一个模型，说出来的可能和他心里想的模型不一致，这就需要架构师设身处地地站在用户的层面思考，针对用户的真正需求设计架构。



---

#### 架构师必备技术

 必备各种流行技术

```txt
知道所有的主流框架，技术的原理和用途；
比如：
  负载均衡是什么？热备又是什么？穿透DB是什么意思？怎么我取数据库里取一个值，数据库里没有，这种空数据的请求会把DB打跨？为什么还要把这些为Null的请求单独缓存起来？本地缓存做为一级缓存，Memcache做二级缓存？“对缓存来说，最关键的设计就在于失效策略是什么。”不同的应用场景，对于缓存的要求不一样，对实时性的要求也不一样。榜单这种一天更新一次的，每天晚上定时生成一次就好了。后台更新，但是要注意，一定要直接生成，直接切换，不能让前端用户访问的时候，再去生成。对于名字这种东西，用户改完之后，必须立刻更新缓存，包括本地缓存和远程缓存。
  而且，原来不应该把所有的代码放到一个WEB里，原来分布式是这么回事儿，原来一个系统，是由多个子系统构成的，原来还要分层，原来封装和抽象是这么个意思。WEB层是一层，通常可以通过LVS部署两台到三台，或者是更多的，Service一层用来处理业务逻辑，缓存层用来扛并发，一定要藏在Service里面，Controller调用Service的时候，并不需要知道，数据倒底从哪来的，每一个Service使用什么样的缓存策略，完全不需要Controller层知道，持久化，对，对于大型应用来讲，Mysql只能用做是持久化，Mysql的单条访问速度并不查，只是在并发能力太差，扛不住。但是，有可能数据量过亿啊？过亿怎么办？是用分库，还是分表？读写分离要不要做？一台服务挂一台数据库，哪些数据库应该放在一个实例里，哪些应该单独拆出去？每台服务器的配置是什么？
  架构师需要从前到后都要懂，他需要制定关键的技术细节，他需要给出最佳实践，他需要了解业界所有流行的解决方案，他需要去猜测Facebook怎么解决问题的，Twitter怎么解决问题的，Google怎么解决问题的，这些解决方案可不可以拿过来，也同样适用于我们自己的场景。他需要精通分布式，Nginx或者是F5，微服务，缓存，持久化，消息队列，他需要熟悉所有这些技术细节里的最常用的解决方案，不能有遗漏，也不可以过度设计，他决定的不是他一个人喜欢的风格，他决定的就是整个团队，在项目死亡之前都必须遵循的规范，现在的团队成员，和未来的团队成员，都必须遵循的体系，而且，如果在未来，这些架构体系有不合理的地方，那就麻烦大了。

然后架构师根据各种需求，把这些大的骨架定好，然后其他人去填充里面的内容。

架构师当他拿到需求时，并不单纯是考虑这个需求怎么实现，还会考虑，自己设计的架构体系，扩展性在哪里，在他的眼里，看到的需求会被分解，折分，然后自己的技术方案，会挨个分解，分配。在完成设计之后，他会很清楚的知道 ，自己设计的系统里，哪些变化是支持的，随便你改，我只需要改动一个很简单的内容，哪些是你绝对不能改的，你要改，我就必须花很大的代价，特别是在已经有线上数据的时候。

总结：架构师要精通各种框架、安全、运维等技术。还要精通算法和设计模式，设计出来的软件高内聚低耦合。是开发岗和算法岗的顶尖。

---

架构师要知道的真相

架构师要掌握的核心思维就是：技术最终为了业务，业务比技术重要！。

解释：

• 客户给了我八千块钱订金，让我帮他做一个“外卖系统”的服务器端，桌面程序，H5移动端，还有android端。这就有了需求。

• 我针对用户的需求，规划出了业务。

• 我针对业务，规划出了用“springboot做服务器端”，“QT做桌面程序”等等。

• 我把最终软件交给客户。

• 客户使用了半年后给我反馈，说用的人一多就卡。

• 我又给加了三台服务器，把请求做成分布式，做一个负载均衡。

• 客户觉得很满意，把剩下五千块给了我

分析上面的过程：先有了需求，然后演变出了技术（我如果服务器端用javabean+servlet+jsp开发得开发一年，用springboot这种框架三个月搞定），然后技术慢慢满足不了需求了，便催生技术的升级，最后需求满足。

---

以上内容由作者看别人博客总结而来，不要盲目相信，要有自己的见解。

然后架构师根据各种需求，把这些大的骨架定好，然后其他人去填充里面的内容。

架构师当他拿到需求时，并不单纯是考虑这个需求怎么实现，还会考虑，自己设计的架构体系，扩展性在哪里，在他的眼里，看到的需求会被分解，折分，然后自己的技术方案，会挨个分解，分配。在完成设计之后，他会很清楚的知道 ，自己设计的系统里，哪些变化是支持的，随便你改，我只需要改动一个很简单的内容，哪些是你绝对不能改的，你要改，我就必须花很大的代价，特别是在已经有线上数据的时候。

总结：架构师要精通各种框架、安全、运维等技术。还要精通算法和设计模式，设计出来的软件高内聚低耦合。是开发岗和算法岗的顶尖。
做这活，恐怕我们凡人真得赌上自己的所有时间精力才能升任。