架构设计的目的
架构设计的主要目的：是为了解决软件系统复杂度带来的问题。
个人感悟是：架构即(重要)决策，是在一个“有约束的盒子”里去求解或接近最优解。这个“有约束的盒子”是团队经验、成本、资源、进度、业务所处阶段等所编织、掺杂在一起的综合体(人，财，物，时间，事情等)。架构无优劣，但是存在恰当的架构用在合适的软件系统中，而这些就是决策的结果。
软件系统复杂度
软件领域的复杂性体现在两个方面：
1. 结构的复杂性
结构复杂的系统几乎毫无例外具备两个特点：
-
-
组成复杂系统的组件数量更多；
-
同时这些组件之间的关系也更加复杂。
-
2. 逻辑的复杂性
意识到结构的复杂性后，我们的第一反应可能就是“降低组件数量”，毕竟组件数量越少，系统结构越简。最简单的结构当然就是整个系统只有一个组件，即系统本身，所有的功能和逻辑都在这一个组件中实现。
不幸的是，这样做是行不通的，原因在于除了结构的复杂性，还有逻辑的复杂性，即如果某个组件的逻辑太复杂，一样会带来各种问题。逻辑复杂的组件，一个典型特征就是单个组件承担了太多的功能。
架构设计三原则
1 合适原则：合适优于业界领先
架构无优劣，但存合适性。“汝之蜜糖，吾之砒霜”；架构一定要匹配企业所在的业务阶段；不要面向简历去设计架构，高大上的架构不等于适用；削足适履与打肿充胖都不符合合适原则；所谓合适，一定要匹配业务所处阶段，能够合理地将资源整合在一起并发挥出最大功效，并能够快速落地。
2 简单原则：简单优于复杂
"我没有时间写一封短信，所以只好写一封长信"。其实，简单比复杂更加困难。面对系统结构、业务逻辑和复杂性，我们可以编写出复杂的系统，但在软件领域，复杂代表的是“问题”。架构设计时如果简单的方案和复杂的方案都可以满足需求，最好选择简单的方案。但是，事实上，当软件系统变得太复杂后，就会有人换一个思路进行重构、升级，将它重新变得简单，这也是软件开发的大趋势。 简单原则是一个朴素且伟大的原则，Google的MapReduce系统就采用了分而治之的思想，而背后就是将复杂问题转化为简单问题的典型案例。
3 演化原则：演化优于一步到位
大到人类社会、自然生物，小到一个细胞，似乎都遵循这一普世原则，软件架构也不例外。业务在发展、技术在创新、外部环境在变化，这一切都是在告诫架构师不要贪大求全，或者盲目照搬大公司的做法。应该认真分析当前业务的特点，明确业务面临的主要问题，设计合理的架构，快速落地以满足业务需要，然后在运行过程中不断完善架构，不断随着业务演化架构。恰恰“演进原则”很多人不知道，总想一步到位，过度设计
注意：高可用，高性能，易扩展，低成本这些是业务的需求，别变成架构师的追求，一旦追求就麻烦了
如何理解wbs系统架构？
根据架构设计的主要目的：是为了解决软件系统复杂度带来的问题。不同时期的系统，锁面临的系统复杂度是不同的
那在wbs2.1.5时期，wbs系统的复杂度在哪呢？在于逻辑的复杂性：wbs2.1.5版本时，整个wbs系统的所有模块，都在一个项目中。导致了修改任何一行代码都要谨慎再谨慎，但这种谨慎仍然无法避免影响其他模块。
(下图来自jira：查看了一下wbs系统wbs2.1.5相关标签，总共有1930个bug)
为了解决当时逻辑的复杂性，明哥入职后一直致力于对服务进行拆分（简称服务化阶段）。
所有团队成员在经过了一年的学习、探讨、实践、入坑、填坑，最终形成目前wbs服务化系统架构：根据业务类型拆分出PASSPORT、CSC、PDC、RSC、配置中心、BS等中心。
记得那时候开始做服务化拆分时，团队在讨论服务治理框架是使用SpringCloud还是使用dubbo，当时整个团队只有明哥在生产环境项目中使用过SpringCloud，其他人虽然没有用过SpringCloud，但是却非常希望服务治理框架使用SpringCloud，为此钟老师还为我们做了异常SpringCloud的技术分享，我们都下载了SpringCloud的学习视频，每天上下班在地铁上在学习SpringCloud。但是最后的最后，明哥却拍板说使用dubbo作为服务治理框架。当时我们脸上笑嘻嘻心里mmp。
但是根据架构设计三原则的合适原则来分析的话，当时选择dubbo作为服务治理还真是明智之举啊！
来源：oschina
链接：https://my.oschina.net/anxiaole/blog/3176061