• 目的

• 
  

  • 架构设计的真正目的

  • 举个例子

  • 最终总结

  • 参考阅读

架构设计的目的

前面我们分享了《什么是架构》、《架构设计的历史背景》，今天来聊下架构设计的目的。个人经历的大至数万人公司，小至百十人公司中，对于架构师这个岗位并非如大家所想。比如：数万人公司我们当时的事业部也多达数千人，当时负责的项目成员也多达数百人，但却没有架构师这个岗位。随后就业的两家百十人公司中，却不得不安排不安排架构师这个岗位，但其中一家因为新增了架构师后各类问题逐渐迎刃而解，而另一家公司架构师却雷声大雨点小，因为耽误频繁延误业务进度被反感，以致最后不得暗然离场。所以，大家知道了，架构师不好做，架构设计是一门技术活。接下来，我们来讨论下架构设计的误区。

• 误区1：架构很重要，所以要做架构设计

架构当然很重要，但为什么重要，重要在哪里，主要因为什么而重要却不一定每个人都知晓。如果不知道：

1. 分层架构

2. 事件驱动架构

3. 微核架构

4. 微服务架构

5. 云架构

眼花缭乱的架构哪种才适合公司，很难做好选择

• 误区2：做架构设计，为了开发效率

做好架构设计就一定能提升开发效率吗？这个答案是不一定哦。有创业经历的朋友知道，创业之初大家各司其职，谈不上团队合作更谈不上架构设计，但大家开发效率奇高质量还不错，随着功能的快速变更，不得不组建团队，以团队合作方式协作时，反倒整体效率会下降很多。所以架构设计就一定能提高开发效率？ 还真不一定哦。

• 误区3：做架构设计，为了提升业务访问速度

架构设计和访问速度有关系，但没有直接关系哦。如果这是面试，你已经挂了，也可能是面试官故意挖坑考验应试人。

• 误区4：公司流程要求，系统开发前要做架构评审

绝大多数公司为了保障代码质量会设置一定的规范来确定大的执行层面代码不会有大问题。因此，在一些大公司常见写代码前先架构评审。通过后再着手写。好处当然有，比如整体代码统一规范，易于维护；新人上手成本低等，但随之而来的问题也不会少，比如：真的需要评审吗？架构师每天都很忙，能响应到每个人吗？（万一）架构师被调岗支持新业务，人员的依赖性怎么解决？所以，为了架构而架构是不对滴。

• 误区5：考虑未来业务高可用、高性能、可扩展，所以做架构设计

能了解到这层的朋友多数对架构设计有一定的思考。之所以做架构设计就是为了解决未来可预期和不可预期的业务发展。但往往新手架构师会因此给业务带来巨大灾难。为什么这么说呢。

架构是演变出来，而不是设计出来的。很多新手架构师初做架构师总有一番设计超牛逼架构的想法。微信的架构很厉害，我们要参考；淘宝的架构很牛逼，我们要学习。不管三七二十一拿来套用，最后发现业务根本不适用，技术人员无力支撑，出了问题没有能力解决。要知道，无论是淘宝还是微信，他们即有超大体量的支撑，又有强大的平台团队背后支持，出了任何问题几乎没有他们解决不了的事情。想想看，自己的公司技术实力是否达到1%了。

架构设计的真正目的

架构设计的主要目的是为了解决当下或未来软件系统复杂度带来的问题，而架构其实并非设计出来，而是随着业务的发展逐步演变出来的结果。遵循这条规则，很多问题都会迎刃而解。

• 微信和淘宝的架构这么牛逼，该用哪个呢？

这类问题在了解架构设计的目的后，就很好回答了。哪个和自己的业务最贴近就使用哪个，或者都不合适的可能性更大。

• 我们的TPS计划做到10W。

计划归计划，宣传资源和市场投入资源到位了吗？预计投入收益比多少？我们人员是否齐备能够支撑这么大量级了。

• DOCKER很流行，我们也要跟上时代

不为焦虑付费，不为盲目埋单。DOCKER是为了解决资源重用和快速部署问题，如果我们没有此类需求或问题，大可不必跳进深坑。

举个例子

互联网发展初期，多数没有什么流量，为了节省成本，很多公司可能就是一个门面站点，这时的需求就很简单，“能用”。构架设计多数是这样的：

• 架构初期

这类架构比较适用于初创企业或流量较小的平台。

此种架构一般都是在平台运行之初所用到的架构，日均PV不大，简单的架构足以能够应对用户的流量请求，比如前端网站使用Apache/nginx都可以，APP服务器直接使用JAVA环境如tomcat应用，互联网平台的数据库大部分使用Mysql，备份服务器一般都备份一些常用的配置、代码、数据库数据的备份文件等。因此，民工哥称它为架构之初。

• 架构中期
  随着用户数量的增长、访问量的增加，随之而来的问题就是单台服务器已无法承受用户的访问流量，因此前期的基础架构就需要面临一定的调整，大概调整如下

这类架构就此引入了负载均衡的概念，关于应用的负载均衡，前面也有相关的文章介绍，具体使用何种方式，一切以企业实际需求、投入与产出比（成本考虑）为主，但是此类架构也有一定的缺点存在，暂时不考虑前端负载设备的高可用，比如用户的上传与查看文件问题（通过A服务访问上传，然后负载查看时是通B服务器的，就会造成用户无法查看的问题），APP服务器同理；数据库服务器存在主、从库单点问题，一旦故障，可以手工进行故障切换，但是可能会造成数据丢失或不统一，并且会在一定程度上给用户造成不好的体验；因此仍需演变。

• 架构中后期

此架构在上面的架构基础，以应对各类问题做出的修改，增加了数据存储服务器（NFS共享存储Linux系统NFS网络文件系统），对于存储架构及源件，其实挺多的，具体有以下几种开源软件服务

1、NFS网络共享存储文件系统

2、FastDFS 轻量级网络文件系统(参考文章：分布式文件系统FastDFS详解)

3、分布式文件系统MooseFS

4、GlusterFS文件系统

并配置负载均衡、并且还解决了单点故障的问题，对于数据库服务器做出了一定的架构调整，为双主多从的架构，对于数据库的各种高可用架构。

但是所有架构都是要以实际需求（如对数据完整性、一致性的要求为主），从而解决主库单点问题、从库读取量大的性能问题，保证在一定量用访问时的平台性能与高可用

• 架构后期

架构演变到一定程度，仅通过平行的扩展或增加服务器数量可能已无法解决相关的性能问题，因此

• 第一：在用户访问初始阶段就会使用CDN加速技术，来提高用户的访问体验度；

• 第二：按照业务来拆分成不同的服务，通过拆分服务、相同服务布署多个实例的架构来达到扩展的目的，来提高一定的性能，也能保证平台的高可用性；服务拆分后，也能一定限度的解决发布问题，因为服务之间彼此独立，服务之间耦合性不强，也比较方便平时的维护；

• 第三：对于用户与数据库之间的瓶颈问题，考虑加上缓存技术来提高一定的访问性能与高可用性，让用户的访问流量在到达数据库之前直接过滤掉一部分，甚至一大半，从而减轻数据库访问压力，在查多写少的场景，非常适用使用缓存来提升查询服务的性能，减轻对数据库的压力。通常使用redis作为缓存服务器，redis的一些集群机制能很大程度上保证缓存服务的高可用性（Redis集群生产环境高可用方案实战过程），缓存服务故障时，还能从数据库获取信息。然后对于备份服务器也简单的做调整保证数据的完整性，一方面也能及时保障应用的高可用性；其实一些大型分布式的系统在缓存这块还是比较倾向于memcached服务（Linux系统Memcached服务介绍），比如像一些用户的登录信息同步到其它系统此种场景，一般布署在前台应用层与数据存储层中间，应对前端应用大量请求与快速响应，从而减少数据库的访问压力，也能提高用户的访问体验度。

也有一部分平台架构是采用分层的方式

前端应用层：

• 给用户提供页面展示、查找、搜索的界面及相关的最终结果显示页面

后端服务层：

• 一般包括像常用的后台服务、用户管理、接口管理、支付管理等，都是给前端应用提提供服务的

数据存储层：

• 这个就很容易理解，像数据库、文件系统、缓存等一系列提供数据访问与存储的
  所以因此也有下面的这类架构产生

最终总结

架构设计只能说是一个阶段、一个时期的，没有完美的架构，只有不断演变、不断完善的架构。因此，今天所说的高性能、高可用架构，可能不尽完美，但归根结底总结成一句话：“让用户的访问流量尽量靠前，一步步分层去过滤用户流量，快速响应用户的请求，从而达到比较好的用户体验”。

参考阅读

• http://blog.51cto.com/mingongge/2112561

• 《从0开始学架构》

永久地址：https://www.ssforce.cn/

*********千人系列群**********

以太python小范围沟通群：662769442

Ansible中文权威主群(3)：372011984

AWK&SED企业实战(3)： 260039357

Docker企业架构实践2群： 491533668

ELK企业架构(2)： 378216203

相关阅读：

架构师之路：什么是架构

架构设计的历史背景

---