架构设计三原则
成为架构师，可以说是绝大多数开发者的梦想。但是这个过程并不是一件简单的事情，如果简单的话，意味着供过于求，就代表着不值钱了。在目前国内，架构师也算是一个比较吃香的职业。对于年龄较大的小伙伴们，他们的选择通常有这么几个?
第一、继续开发者之路，毕竟现在30多岁的资深工程师也不少(通常这些人，对于公司来说，业务非常熟练(某工程师对公司好几个业务十分熟悉，不少项目其中的核心代码是其编写(另外也考虑到如果真正是新人来对接，时间成本或者其他方面的成本是比较高昂的)，同时也比较稳定(基本上都已经成家有了自己的小孩，跳槽的频率相对小）;
第二、走向管理之路，管理之路，通常是要么是项目经理，要么是TeamLeader，大小公司对此有不同的定义，有的规模毕竟大的公司，可以细分为项目总监、项目经理及其CTO或架构师;
第三、转向产品或者运营方面;
第四、去当教师(通常去培训机构当讲师);
第五、自主创业(不过不多，一般情况下，充当技术合伙人的比较多，因为当技术合伙人，仅仅只是负责技术方面的设计和管理，不必承担金钱方面的风险);
第六、自由职业(一般自由职业，通常是接私活，前提是私活足够多，一般这种自由职业者通常身边会有几个在职或者非在职朋友一起合作,毕竟人多力量大）；
第七、成为专职作家(毕竟对于程序员来说，能够写书，将自己多年对技术方面的掌控和理解等分享给广大的小伙伴们也是一件非常幸福的事情);
第八、没有办法不得不转行(技术不过硬、人脉又不好、业务方面积累不深或者是在该领域十多年过去了，仍然做着重复的事情，而今有比其价格更低的人来替换其);
这篇文章不是再讲程序员的以后方向和怎么走接下来的路。主要还是围绕着架构设计三大原则。上面的话只不过是临时突然有些想法，所以就说说了。
另外贴一下架构师的薪资(以北京一线城市为例):
用友公司:
联想集团:
从中可以普遍看到架构师的薪资通常在20K以上。当然了，能拿到多高，取决你自身所能提供的价值。
文章偏题太多，下面进入正题。
问:架构设计三原则有哪些？
答:主要有合适原则、简单原则、演化原则。
一、合适原则
优秀的技术人员都有很强的技术情结(包括我自己，虽然在技术方面不够优秀还需要学习很多东西),当他们做方案或者架构时，总想不断地挑战自己，想达到甚至优于业界领先水平是其中的一个典型表现，因为这样才能够展现自己的优秀，才能在年终KPI绩效总结里面骄傲地写，“我设计了某某方案，达到目前知名某公司的一样效果甚至优于其”。
但现实是，大部分这样想的和这样做的架构，最后可能都以失败而告终。
为什么会这样?原因有如下几个方面?
首先再理想的设计，也需要考虑实际情况，我们可以叫做实事求是或脚踏实地。
(1)将军难打无把握之仗；
在互联网公司，一般情况是你有多少个人就表示你能做的多么大，也许这个观点你并不赞同，比如阿里为例，最早的阿里公司肯定没有现在这么多人，系统也没有这么大，起初都是从几个人开始的。关于这段历史，大家有兴趣可以看看关于阿里方面的传记或者马云先生的传记。
(2)罗马不是一天建成的;
这个不用多说，一看就明白，前面(1)也是如此。
(3)冰山之下才是关键;
可能有人认为，业界领先的方案都是天才创建出来的，所以自己也要造一个业界领先方案，以此证明自己也是天才。确实是有这样的天才，但更多的时候，业界领先的方案，其实都是“逼”出来的。
比如以之前某公司的一个产品经理需求为例，APP的背景根据手机壳变色。这个需求并非是不能实现的。当然了，这个需求看起来有些操蛋。
简单来说，“业务”的发展到一定阶段，量变导致质变，出现新的问题，已有的方式已经不能应对这些问题，需要用一种新的方案来解决，通过创新和尝试，才有了业界领先的方案。
比如有不少IT小伙伴们动辄就说分布式、大数据、微服务之类的，但是前提是当业务发展到一定阶段时遇到瓶颈，现有的架构或方案不能满足业务的扩展。
二、简单原则
软件架构设计是一门技术活。所谓技术活，从历史上看，无论是瑞士的钟表，还是瓦特的蒸汽机;无论是莱特兄弟发明的飞机，还是摩托罗拉发明的手机,无一不是越来越精细，越来越复杂。因此当我们进行架构设计时，会自然而然地想把架构做精美、做复杂，这样才能体现我们的技术实力，也能够将架构做成一件技术品。
前面我在谈谈架构设计的目的 这篇文章中说过，架构设计的目的就是应对并解决软件日益庞大复杂的问题。
关于软件领域的复杂性主要体现在这么几个方面?
1.结构的复杂性
比如最初在单体应用上，所以的请求集中在一个项目上，后来从这个整体系统，分出几个子系统来，于是每次提供服务，都需要关联这几个子系统以达到实现功能的目的。一个两个还好，但是三个四个乃至十个二十个，会怎么样呢？我的回答是，你可以以HTTP请求为例，请求有的时候也会因为网络延迟或者请求携带参数的问题导致请求失败，你试着想像，为实现某一个功能关联几个子系统(需求请求几个子系统)，我相信你就懂了。
通过这个例子，我们可以发现结构上复杂导致的问题有很多，以下我列举几个常见的问题?
(1)组件越多,就越有可能其中某个组件出现问题（组件你可以理解为多个子系统）;
(2)某个组件改动，会影响关联的所有组件(从某个角度看，你可以理解为耦合性比较强);
(3)定位一个复杂系统中的问题总是比简单系统更加困难;
2.逻辑的复杂性
意识到结构的复杂性后，我们第一个想到的可能是降低耦合性，如何降低呢？可能引用设计模式来达到这个目的，也有可能是减少分出的子系统数量来达到这个目的。
但是最粗暴最简单最实际的做法就是，就是不分出子系统(组件)，全部在一个系统上。
糟糕的是，这样是行不通的，原因不仅仅是因为结构的复杂性，还有逻辑的复杂性，比如如果某个组件的逻辑太过复杂，一样会带来不少问题。
关于逻辑的复杂性，我想强调一点是，为什么程序员经常加班，先不说代码质量问题(毕竟如果不是公司有一定的规章制度约束你，让你必须这么做，有的时候，我们为了图快，很少考虑代码整体的简洁(优雅)或有没有更好的实现方案，一般就是拿起键盘立刻实现完成任务就OK，因为在大多数情况，我也是这么做的，没有比在短时间内尽快完成上面交代下来的任务更为重要，毕竟薪水和享受的待遇掌握在上面手里)。有一点与代码质量关系不是特别大，那就是业务的复杂度，过于复杂的业务，涉及好几个系统，万一改了这个没有改好，就会影响其他的系统。
三、演化原则
其实软件的变化就好比生物的进化，并不是一蹴而就的。它也有一个演变的过程。
以生物为例:
(1)首先，生物要适应环境;
(2)其次，生物需要不断繁殖，将有利的基因传递下去，将不利的基因剔除出去;
(3)最后，当环境变化时，生物能够快速的适应环境，如果不能适应自然就会淘汰(这也就是严复曾经说过的“物竞天择，适者生存”);
软件架构设计同样是类似的过程:
(1)首先，设计出来的架构要满足当前的业务需求(毕竟公司盈利是首要目的,不然，哪有钱发工资或者享受公司的各种福利呢);
(2)其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善;
(3)最后，当业务发生变化时，架构要扩展、重构，甚至重写;代码也许需要重写，但有价值的经验、教训、逻辑、设计等(类似生物的基因)却可以在新架构中延续下去;
架构师在进行架构设计时需要牢记这个原则，时刻提醒自己不要贪大求全或者盲目照抄。应该认真分析当前业务的特点，明确业务所面临的主要问题，设计合理的架构，快速落地以满足业务需要，然后再运行过程中不断完善架构，不断随着业务演化架构。
小结:
架构设计三原则已经谈完了，希望给小伙伴们有所启发。
