小谈架构

     我最近也是刚刚接触架构，暂时了解了一下皮毛，拿来现学现卖，不足之处还希望网友指正呀。

     架构这个东西一开始我并不是特别想要深入了解，觉得那是顶级设计师的事，和我们普通程序员关系不大，但是后来有朋友推荐了一下，看到一些老程序员对于职业规划的建议，感觉还是得努力努力。

   1.架构的含义

    架构一词最早来源于建筑行业，可以理解为在破土动工之前，设计师需要对建筑设计构图，没有架构，大楼随意设计可不行。软件行业也是一样，一个系统在开发之前也是需要设计的。

  2.架构设计三原则

      通常架构的难点在于选择，为什么呢？因为很多事情从长远来看是不确定的，而且软件行业日新月异，新的技术层出不穷，我们需要基于一定的判断去选取合适的方案。

       而且既然是设计一个全新的东西，就意味很多时候并没有一套通用的规范来参考，这时候就需要架构师丰富的经验和敏锐的直觉了，听起来还是蛮有挑战性和创造性的。

    这三原则就是：合适原则，简单原则，演化原则。

   1）.简单原则，合适原则

      合适的才是最好的。

       很多人常有的错觉之一就是越复杂，越高端。复杂也分很多方面，第一个方面就是结构复杂，假设每个组件的故障率为10%，那么系统有两个组件的时候，故障率为9%。3个为27.1%。5个就是41%。由此可见，组件越多，故障率越高，对于用户来说，体验一定很差。体验差了就没有人用了，再高端的软件也就成了摆设。其次，结构的复杂性还体现在bug的修复上，组件越多，定位bug的难度也就越大。

    其二，业务逻辑复杂，假设有将所有的功能点集中到其中一个组件上，上百人在维护，只要一人出错，极有可能导致系统奔溃。接下来还会有源源不断的需求，导致版本变来变去。相信没人会受得了。为什么会导致这样的情况呢，因为上线并不代表结束，接下来还会有更多的需求需要完成，如果系统过于复杂，每修改一个版本就有可能牵一发而动全身。

  2）.演化原则

     演化优于一步到位。

    上面提到过，上线并不代表完成了，因为在一个软件的生命周期中，系统是需要通过业务的发展而不断变化的。如同生物进化一般，物种的形态在随着地球环境的变化而变化，过去是，现在也是。

   所以，首先需要设计出满足当时的业务需求的架构，然后才是在业务发生变化时能够满足变化的需求。尽量不要贪大全，一劳永逸。

3.成功案例

      好的成功的架构案例有很多，今天就拿淘宝来讲讲。说出来你可能不信，淘宝最初的架构是。。。买来的。没错，淘宝从2003年4月7号宣布成立，到2003年5月10号上线，只用了一个月左右的时间，国内电商的佼佼者竟是买来的，你可能会问，马云究竟是怎么想的？

    因为淘宝在初创的时候，国内的电商行业才刚刚起步，所谓兵贵神速，迅速抢占市场才是王道。因此依照简单和合适原则，不需要过于考虑技术上的问题。比如当时使用的就是mysql数据库。直到过了一段时间，mysql已经无法承受的时候，才替换了oracle。而最初，淘宝使用的是PHP，后来才使用的java。就是因为当时java是最成熟的网站开发语言。虽然当时请了sun公司的人来开发，但是并不是买来的现成的系统，架构设计遵循了演化原则。随后，随着阿里巴巴的壮大，淘宝已经完全有能力去自主优化系统。所以后续的架构基本上都是在围绕业务在演化。

未完待续。。。。。

转载于:https://my.oschina.net/u/3860506/blog/1815376