一个应用越大，启动时间就会越长，大部分时间就要在等待中度过，生产效率会受到极大影响。
另外，一个应用在与其他模块发生资源冲突时，扩展将会非常困难。应用的另外一个问题是可靠性，当所有模块都运行在一个进程中，任何一个模块中的一个Bug，比如内存泄露，都有可能弄垮整个进程。除此之外，因为所有应用实例都是唯一的，这个Bug将可能影响整个应用的可靠性。
如果采用微服务来处理结构模式则可以很好地解决上述问题。微服务架构的思想不是开发一个复杂巨大的应用，而是将应用分解为若干小的、互相连接的微服务。
5.3
常见问题分析
5.3.1 无从入手
现代的软件从业者，都受过良好的计算机和软件方面的教育。但是现代的计算机和软件方面的教育，基本上都是从科学研究领域脱离出来的，教育的主要目的理所当然的是为科学研究领域服务。而随着社会的发展，软件不断地渗透到不同的业务领域，涉及普通人生活的方方面面。以科学研究为目的的软件教育，和日益深入人们生活的软件应用产生了很大的隔阂，以致很多计算机和软件专业毕业的学生进入企业工作后，总是感叹学校所学习的知识没实用价值，必须得重新学起，才能够达到企业的要求。
系统架构和上面的描述很像，貌似你看了很多的书，市面上也确实有很多例如“分布式系统架构”“微服务架构”等跟随潮流的书籍，但是看完后只停留在会采用一些开源框架进行整体框架搭建（注意，我说的是搭建，而不是设计）。确实是搭建，你所拥有的能力就好像小孩子搭积木，只会采用固定套路，或者学得差点的连固定套路都不会，这样对你的个人发展其实没有多大好处，这也是为什么很多程序员在完成了程序员到架构师的转型后，没过多久就转为纯管理，或者彻底离开了技术界。因为他们从来没有大彻大悟地理解系统架构。
如果你发现一个人画出来的总体架构图有点奇怪，没有区分服务端、客户端，这时候你可以猜测他并没有真正理解什么是系统架构，他更多的是以模块方式进行切割，而不是从架构设计角度思考。出现无从下手或者随意下手的情况，真正的原因都是不理解，建议大家从软件系统架构基础类的书学起，不要一开始就看基于潮流框架的架构书。
5.3.2 轻视设计
一般来讲，职场新兵在设计业务系统的时候，容易出以下几个问题：
·需求沟通完，马上就开始设计数据表结构，就想着有哪几张表、要建哪些索引、有哪些唯一键、如何保证事务、如何设计触发器等。出现这类问题很正常，毕竟在学校学的都是理论，授课的老师很多没有太多的工程经验，也指导不了你的设计。
·要他设计一个系统，完全摸不着头脑，一提笔就是写代码，想到哪里写到哪里，没有一丝设计。出现这类问题的同学，一般都是在学校没好好学习的同学，或者是非计算机专业的同学。
·而有一些工作经验的人，做出来的设计也是一团糟，不是考虑不周全，就是画的图别人看不懂。这类人一般是平时不喜欢看书学习，或者是之前刚工作的时候没有有经验的人指导。
架构师需要参与到项目开发中，这样团队成员就不会出现轻视设计的情况。架构师参与项目需要分阶段。
5.3.3 技术优先
技术本身是没有好坏的。比如最早的计算机软件是单机运行的，而后逐渐发生了架构拆分，最终形成了C/S的架构，随着互联网技术的发展又成了B/S，其实这都是换汤不换药，Browser还是一个Client。但是因为Browser的普适性，又做了一个架构拆分，成了一个通用的Client，做到了很多C/S时代做不到的事情。互联网时代的技术人员对C/S架构不太认可。到了App时代，又回到了C/S时代的做法，因为HTML5响应慢，无法适应手机客户端。所以说，随着人们问题的不断变化，会有不同的技术周期出现，技术有自己的生命周期。没有永远最好的技术，也没有永远最差的技术，问题总是在不断发生变化的，对于这一点，架构师要有清醒的认识。
我其实不太喜欢面试培训班出来的技术人员，他们可以滔滔不绝地和你描述各种框架的使用，细微到某一个参数，每遇到这种场景，我真想用英语说“I don’t care。”并不是有偏见，而是我真的不在乎你懂不懂参数的配置，我要问的是计算机科学基础知识，可以聊算法、聊数据结构、聊设计模式、聊你参与过的系统架构设计、聊内存管理机制和垃圾回收机制、聊你对于技术的情怀。框架的选择，实质上是对技术可行性的选择，这又需要符合当前的业务形态，所以，没有哪一个技术或者框架是最好的，只有最适合你的产品需求的，才是最好的。
想做好技术的使用者并不容易。架构师必须深入了解不同的技术，知道这些技术的强项和弱点，懂得合适取舍。
技术人员如果要成为架构师，就必须跳出技术的视角，换一个角度去看技术。要把时间花在研究生命周期规律和业务的增长上，花在选择合适的技术上，而不只是追求新潮的或自己喜欢的技术。在很多人看来，特别是软件工程师，架构和技术是完全等同的。多学会几种技术，就觉得可以做架构师了，或者学会的技术越多，就觉得自己的架构水平越高。对于别的架构师也会采用同样的标准来评判。你要知道，任何技术都是为了解决某种问题而存在的，学会了很多技术，并不代表能够利用这些技术来解决问题，学会的技术多只是解决问题的手段多了一些而已。
架构师需要很冷静、很平等地对待所有的技术。对于软件架构师来说，他们要深刻地领会软件开发生命周期和软件运行生命周期，以及业务的生命周期，并把它们合理地组织、结合在一起，能够通过软件的快速增长来支撑和顺应业务的增长。这些是软件架构师的核心能力。为达到这些目标，无论是新的还是旧的技术、先进的还是落后的技术，只要场景合适，他们就会采纳。因为架构师是技术的使用者，他们把技术当作解决增长问题的手段和工具，而不会被技术束缚住。
5.3.4 业务困境
业务和架构都是处理人的问题，而技术人员最讨厌处理的就是人的问题，内心厌恶，却又无法逃避。因为这个排斥的心理，工作中始终想避开和人有关系的地方。因此在做技术之前，还需要做一些准备工作，用来连接现实生活，让大家知道处理人的问题并不可怕。建立了这个相关性，每个人就都可以自行思考。
其实对于做软件的技术人员而言，技术也可以分为两部分：一部分是软件技术，另一部分是业务技术。当前软件行业所说的技术，基本上都是指软件技术和计算机相关的技术，也就是软件的访问生命周期所涉及的技术，比如服务、存储等相关技术。软件技术大部分集中在软件的访问生命周期部分。业务技术这一块，软件工程则较少涉及，这部分主要隐藏在业务逻辑中。因此在谈技术时，只谈软件技术是远远不够的。不管是软件技术还是业务技术，均来源于对现实生活问题的解决，现实生活才是架构师真正的营养来源。
为什么软件工程师会有时间恐惧和压力呢？原因是他们把按时完成自己的工作当成了自己的最大利益。人对时间的压力是与生俱来的，对业务的不了解也会导致他们没有太大的把握。这一问题在其他行业的表现并不明显，毕竟在其他行业，架构师主要处理的是本行业的问题，对业务比较熟悉。软件行业则较特殊，通常是以业务的问题是否解决为判断标准，是在解决另一个行业的问题，这一点提高了对软件架构师的要求。这就要求软件架构师把完成业务的工作当成自己的最大利益，深入到业务中去。随着对业务的熟悉，对时间的恐惧才会慢慢消失。对业务领域理解得越深入，就越知道如何去发现问题，慢慢就成为业务专家了。只有做到这一点，才能在业务领域建立自信，成为一个合格的软件架构师。
还有另一种很普遍的现象，做技术的软件工程师往往看不上业务，觉得技术更高端，而业务太平凡、太低端，并且业务人员总是给技术挖坑。而业务人员则觉得做技术的眼光高，但总是理解有偏差。技术人员往往对业务一知半解，业务问题总是解决得不圆满，但业务人员对此又无可奈何，因为自己不懂技术。做架构的人必须亲身体验业务，感受业务，才可能真正认识业务的个性，真正认识业务所面临的问题。在理解业务个性的基础上，才能够谈共性。否则这个抽象就像是无根之木，一旦局限于个人的主观认识，很难长大。
如果软件工程师对业务一知半解的话，软件是不可能写好的。在软件开发的整个过程中，参与其中的所有角色，都应该以软件工程师为核心，帮助软件工程师理解业务，让软件工程师成为业务专家。这听起来似乎又回到了科学研究领域的研究人员采用软件的方式，只不过研究院是先学业务再学软件，而软件工程师是先学软件再学业务，顺序不同而已。只有软件工程师成为业务专家，写出来的软件才是靠谱的。
如果业务简单，流量足够小，几个软件工程师就可以了，并不需要其他角色参与。比如一个创业公司，可能几个软件工程师就搞定了。一旦业务复杂度比较高了，或者流量达到一定规模，就需要很好地组织软件工程师的分工。
5.3.5 专职架构师
如果软件架构师不具备组织架构上的权利，那么架构师的设计慢慢就会被弱化，无法落地。软件工程师或者团队领导会按照自己的想法擅自修改或者重构架构，尤其是软件工程师容易不计代价地采用流行的技术或者自己喜欢的技术，甚至会和架构师产生冲突。这种情况下，对于软件架构师内心的冲击会很大，他们往往会选择变成软件工程师，专注于深入软件实现过程，而不顾及软件和业务的增长。
技术人员如果要成为架构师，必须跳出技术的视角，换一个角度去看技术。要把时间花在研究生命周期规律和业务的增长上，花在选择合适的技术上，而不是漫无目的地追求新潮的或是自己喜欢的技术。
对于从软件工程师成长出来的软件架构师，要真正成长为一个架构师，首先需要克服的就是时间困境。从软件工程师的角度出发，首先需要面对的就是可以用自己的软件技术能力去解决业务问题。这些业务对于软件工程师来说，是另一个行业的内容，因此软件工程师对于业务往往一知半解，也没有太大的动力去研究，他们主要专注于完成自己手头的编码工作。如果一个人在工作中，只是致力于完成自己的工作，以做好自己的工作为主要目标，那么用自己行业的知识去理解另一个行业，就很容易出现沟通的困境，造成很多理解上的困难。
当软件工程师需要帮助别人解决问题，并且按时、按需解决业务问题已经成为他们自己的问题的时候，软件工程师就有了时间的压力，潜意识里会自然而然地对时间产生恐惧。这个恐惧会想方设法地推动软件工程师采用各种手段，如加班，以便及时地完成工作。要想成为架构师，必须超越对时间的恐惧，看清楚需要解决问题的主体是业务人员，而不是自己。即需要解决的问题是另一个行业的问题，自己是在帮助业务人员解决问题。这也是软件特别的地方。如果只顾着完成自己的工作，而业务的问题没有解决，那么很可能需要返工，从而导致软件工程师投入更多的时间。工作是否完成是由业务人员决定的，而不是软件工程师自己。
5.3.6 一步到位思想
可不可以把软件架构一步到位地做好？在当前的技术水平下，这基本上是不可能的。一方面在流量不大的时候，做太复杂的拆分会浪费大量时间和不必要的成本；另一方面是因为流量是外在的因素，有经验的人可以做出部分预判，但也没有办法完全预测流量会在哪个地方增长。所以既没有必要一步到位，也不可能一步到位。只能结合运维和运营，及时地探索流量的增长，在流量达到瓶颈之前，根据业务的规律进行合理的拆分，帮助快速地应对增长。这不是架构演进，因为此时业务并没有发生变化，只是流量增长了，把这叫作软件的长大可能会更合适一点。
5.3.7 系统过度设计问题
设计的方案如果不结合目前的实际情况，考虑得太复杂，实现起来也会特别复杂，和造轮子一样，也存在同样的浪费，其实过度设计倒还好，就怕错误设计。比如觉得MySQL性能不好，要加一层Memcached缓存，最后设计并上线使用后发现，缓存命中率非常低，白白浪费了大量服务器，损耗了性能，并增加了系统的复杂性。
2012年支付宝遇到了健康检查系统问题。和所有系统的自我保护一样，这个健康检查系统会定时扫描线上机器，根据机器应答返回时间判断是否正常，将超时严重的机器从应用列表中剔除。在双11的流量之下，几乎所有机器都发生了响应过慢的情况，然后大部分机器都被剔除了出去。发现问题之后，支付宝快速下线了这个系统，支付成功率才重新回到了正常值。
5.4
其他
5.4.1 架构和树的关系
我们每次谈到架构，都需要谈论树状结构，那么树状结构有什么好处呢？树状结构特别适合增长。树状的增长，成本方面最低、沟通的路径也没有显著的增长，带来的效果最好。树的结构也保证了分支的能量汇集到树干，保障了整棵树的生长。而架构恰恰是为了应对增长的，自然而然架构都是树状的。
谈到树，就必须要提到分层。分层实际上是架构树状拆分的结果，所以当我们采用分层的时候，内心先要有树的概念。如果我们直接采用分层的方式设计，最后就会违背树的原则，导致很多复杂的问题发生，从而影响到系统的长大，例如跨层访问形成了图，这就违反了树的原则。
架构的拆分是顺应业务生命周期规律的一种拆分，这个拆分始终是围绕着业务的核心生命周期进行的，结果只有一个：无论如何拆分，它依然是树。
注意，很多人一谈架构就会提到分层，分层的前提是把一个生命周期的连续过程拆分成一棵树，因为有了树才会有层的出现。
5.4.2 为什么会有架构
如果业务足够简单，用户流量足够小，时间要求也不紧迫，那么一个人或者一台机器慢慢实现就可以了。这种情况一般不需要讨论架构的问题，因为不需要并行，即没有时间压力，也没有产出的压力。此时对应的业务通常比较简单，对应的业务组织架构也会比较简单。
当软件对应的业务组织架构越来越复杂，或者当访问的流量越来越大时，就会产生时间的压力，即在相同的时间内需要完成更多的产出。软件会拆分得越来越复杂，机器也会越来越多，甚至同一个软件也需要拆分为多个组件，需要多人合作完成编写。但是业务的核心生命周期，即业务的核心建模不会有任何的变化，还是完成同样的事情。唯一的区别就是会拆分出很多的非核心生命周期，它们以核心生命周期为根，不断地增长，最终形成一个树状架构。生成的架构如下：
1）在软件开发生命周期中参与的人员越来越多，进而形成软件开发团队的组织架构。因为软件代码开发的过程是一个生命周期，必须严格按照时间有序推进，根据开发的核心生命周期进行拆分，形成很多个非核心生命周期。按照软件开发核心生命周期的流程，把不同的非核心生命周期串联起来，使得这些非核心生命周期能够并行开展工作，这就是软件工程。所形成的就是软件开发团队的组织架构。
a）为了让业务在软件中实现并落地，便于用户对软件的访问，需要不同技巧的人同时工作，并对代码进行切分，形成代码的架构。切分的原则就是根据用户对软件访问的生命周期，识别出核心生命周期和非核心生命周期，形成树状架构。从分层的角度进行思考的时候，千万注意不要破坏树的架构。有树才会有分层，有分层却不一定有树。当这些工作由一个人来完成的时候，由于没有明确的分工，不一定会有代码架构，所以代码往往会比较混乱。
b）为了完成业务的工作，需要把识别出来的业务架构和支撑业务的组织架构，以及业务运行的核心生命周期流程，用代码表述出来。
2）在软件运行生命周期中，当软件的流量越来越大时，慢慢就会超出软件所在机器的负荷。这个时候就必须增加机器，软件所部署的机器也会根据用户访问的生命周期，按照树状的结构开始拆分，所形成的是硬件部署树状架构和软件部署树状架构。
5.4.3 业务、技术、架构三者关系
业务、架构和技术之间是共生的关系，而不是互斥的关系。
技术人员很多时候所关心的技术，和业务的主要目标往往不是直接对应的。由于业务和技术属于两个不同的树，也就是说有两个不同的根节点，因此只有沟通才能解决问题。
技术总是在人类对业务目标要求不断提高的情况下产生，其目的是为了获取更大的利益。所以，技术是为了解决业务问题而产生的，没有了业务，技术也就没有了存在的前提；有了更好的技术后，效率较差的技术，就会慢慢被淘汰，进而消失，一切都遵从人类的利益诉求。
不同技术之间有两种关系：
1）在解决同一个业务的前提下，更高效、更低成本的技术会淘汰低效、高成本的技术。这是由人类利益诉求所决定的。
2）通常刚开始解决核心业务问题的核心技术的效率是比较低的，只是把不可能变成了可能。慢慢就会有提高的需求出现，改进技术的要求就会变得很迫切。技术所解决的业务生命周期慢慢就会开始发生拆分。非核心生命周期分离出去后，要么使用现在的技术来实现，要么形成新的技术，服务于更广泛的业务。
在业务生命周期拆分之前，技术是由一个主体串行地执行并工作的，这就是效率低下的原因。从业务生命周期中把非核心生命周期分离出去之后，非核心生命周期会形成新的技术，由不同的主体来执行。新的技术可以独立地与核心技术并行工作，提高原有技术的效率。因为要解决的核心业务问题并没有发生改变，所以拆分所形成的是一个树状的架构。
也就是说，先有业务问题，才会有技术来解决业务问题。而业务的长大要求，提高了对技术的要求，导致了对业务生命周期的拆分，以并行的方式提升效率，形成了架构，也形成了新的技术。所以在这三者的关系里：业务是核心，技术是解决业务问题的工作，而架构是让业务长大的组织方法。架构需要用技术来实现拆分，技术需要架构来合理组织，以提升效率。软件和业务最终是要合体的。
5.4.4 架构拆分要点
需要遵循拆分的原则如下：
1）如果必须要生命周期的主体在连续时间内持续执行，不能够被打断并更换生命周期主体，那么被拆分的生命周期，不能切分出去。
2）每个生命周期的负责人对所负责生命周期的权利和义务必须是平等的。
3）切分出来的生命周期不应该超出一个自然人的负载。
4）切分是内部活动，内部无论怎么切，对整个系统的外部都应该是透明的。
架构切分的过程就是建模的过程。在早期流量不大的时候，往往一个人会同时兼很多工作，一个系统往往也会做很多的事情。在流量增大后系统很快就达到瓶颈，这个时候就不得不进行拆分了。要做拆分就必须要去识别核心生命周期和非核心生命周期，把非核心生命周期切分出来。切分出来的不同子生命周期就形成了不同的概念。所以每个概念背后都是一个生命周期，每个生命周期都是一个模型。核心生命周期模型把所有的模型通过树组织起来，形成了一个新的模型。
架构切分的结果最终都会体现在组织架构上，因为架构的切分是对人利益的重新分配。另一方面，架构切分需要组织架构来保障实施。要为负担重的相关利益人减轻职责和权力，要为负担轻的需增加职责和权力，这里反复强调职责和权力，它们本质上应该是需要对等的。如果所有人负担都很重，就要增加人，从而形成新的架构切分；或者引进新的技术，提升大家的生产力，以形成新的架构切分。所以进行架构切分的时候，往往也是组织长大的时候。
一个好的架构拆分会形成一棵树，慢慢会长大成一片森林。每棵树在这个森林里都能够获得所需要的养分，有自己的空间。每棵树的内在是平和的、舒展的，遵循自己的生命周期规律，顺其自然地长大，一派欣欣向荣的景象。这就是架构的魅力所在。
5.4.5 企业应用架构演进
不论是传统企业，还是互联网公司，发展到一定阶段，都需要一整套体系化的应用架构来支撑其运转。良好的、合理的应用架构可以支持企业高效开展业务，控制经营风险，而混乱的、不合理的应用架构则会限制企业的快速发展，成为企业增长与变革的瓶颈。
完整的企业架构（Enterprise Architecture，EA）分析构建，包括业务架构、应用架构、技术架构、数据架构，这里着重介绍应用架构。
1.什么是企业应用架构
从开发模式上看，传统企业更加倾向于瀑布式软件开发，对研发、运维流程的管理更加严谨，因为传统企业业务变化慢，对系统的每一次调整改造都非常慎重，而互联网公司业务变化调整快，必然要求软件开发时效性高，对软件设计的严谨性做出一些让步，因为很有可能发生的情况是，软件还没有开发完毕，业务或流程已经再次发生变化。
企业IT架构的设计不仅仅是注重某一个系统能力，更需要给企业一个可进化的、可持续发展、不断创新的平台。业务持续变更将成为“新常态”。架构师们不仅需要满足企业IT中高可靠、高安全、一致性、合规性要求，还需要满足创新IT所需要的灵活、快速、伸缩的挑战。
2.企业信息管理模型及案例
企业的信息化管理有很多标准模型，例如COBIT、ITIL、CMMI、ISO27001，这些覆盖了开发管理、服务管理、数据管理等方方面面的规范和标准。很多成熟的互联网企业也会执行使用这些标准来提升IT能力对企业管理效率的提升和经营风险的控制。
当你的企业还是一个小作坊的时候，比如经营一家小超市，这时候你只需要用excel表格就能管理好自己的账目，因为此时无非是类似于进销存系统的买进价格、卖出价格这类统计。你也可以采用科学的数据表格管理，记录门店的所有采购入库和销售数据，这会让你的经营变得井井有条。通过这些原始数据，你可以准确地管理库存，计算利润，掌握畅销品和滞销品，还能通过数据透视表制作销售日报和月报。这已经是一个管理软件的雏形了。
接着由于经营得不错，你的小店逐渐扩大了规模，吞并了旁边的其他小店，有了连锁店的感觉。这时候，你发现管理有问题了，需要引入ERP系统。你选择了一套轻量级的ERP，并且只购买了其中的几个核心模块，这样既可以控制成本，又可以让你经营的软件设备升级。
而后连锁店生意不错，为了更加准确地理解、认识你的客户，同时也为了能够拉近你和客户的距离，你打算通过CRM软件进行更加科学的客户管理。核心的客户信息资产模块都在CRM中实现，其中内置了营销模块、消息推送服务MSG模块，包括SMS、EDM（Email Direct Marketing）和微信消息推送。CRM主要聚焦于客户资料的管理和营销服务，ERP主要聚焦于超市的进销存及财务业务。这时候就有了应用架构设计的概念，公众号、ERP和CRM每个系统都为了解决某一大类的业务问题而存在，有各自清晰的定位、分工和目标用户，每个系统相对独立又互有关联；内置若干模块，每个模块都是为了解决某一大类业务问题下的某一小类问题而设计。
业务进展很顺利，你已经开了五家中型连锁超市了，员工数量达到了几百人。公司走上了正轨，标准化的管理分工已经成型，不同职能单元各司其职。为了有效管理团队，并且让内部流程更加顺畅，你邀请专业的IT咨询公司来帮你重新梳理公司的业务目标、组织架构、运营流程，通过引入OA、HRM以及重构ERP等手段，对不合理的制度、低效的流程进行了改造。公司成立了信息技术部，其中项目部配合咨询公司及软件外包公司进行系统改造或实施新系统；运维部负责保证服务器、网络的稳定。理解数据对公司发展非常重要，所有的管理决策都应该基于对数据的分析和判断，因此你应邀请咨询公司帮你强化公司的数据分析能力。咨询顾问建议你实施数据仓库（Data Warehouse）和BI（Business Intelligence）项目，原因有几点：
1）ERP系统和CRM系统都有报表模块，但两个系统的数据相互孤立，不利于整合分析；
2）业务系统的底层数据结构并不适合做复杂的数据分析，常见的多维分析更需要一套数据仓库常用的星形数据结构和雪花型数据结构；
3）成熟的BI软件套件可以让你的报表分析与多维数据探查更轻松，其中的仪表盘更能够让你轻松掌控公司全局的核心指标变化；
4）企业经营中很常见的一个问题就是经营分析指标统计口径太多，造成管理混乱和沟通障碍，除了在管理上要规范公司级指标的定义外，也需要一套底层数据架构，以消除上游各个异构系统的孤岛和屏障，便于统一管理、汇总数据并进行指标计算。
咨询顾问建议，虽然目前公司的业务系统还没有到非常复杂的阶段，但数据仓库可以帮助企业更快速高效准确地理解、捕获、使用数据，做好基础建设工作，培养员工的数据分析意识和方法，通过数据来进行决策。随着业务的拓展和系统复杂性的提升，数据仓库的存在价值将越来越明显。
由于公司经营良好，很多商品可以从供应商处拿到很好的价格，经过供应商授权，公司决定开展2B业务，成立了大客户销售部，公司将作为供应商的B端渠道，挖掘企业客户。为了让销售工作高效展开，对销售人员进行严格的过程管理，同时也为了保留客户资料，避免销售独占客户资源，根据CTO建议，公司决定实施操作型OCRM（Operating CRM）项目。同时由于各部门经常出现个性化的软件开发诉求，软件外包维护的成本高、效率低，公司决定招聘研发团队，用自己的队伍进行软件的二次开发。
在设计OCRM系统时。CTO面临两个选择。
方案一：新做一套独立于现有CRM的OCRM系统。
优点：OCRM系统已有成熟的软件可以选择，无须从头开发；两个系统边界清晰，分工明确，便于未来各自的发展与演变。
缺点：应用架构会略复杂，需要将原有的CRM和OCRM做数据打通，对原有的客户模型做升级。
方案二：在原有的CRM基础上开发新模块。
优点：新开发的模块完全基于公司业务流程和模式设计，适配程度高。
缺点：新开发模块成本高、速度慢，系统边界模糊，导致以后维护升级时模块管理混乱。
综合评估两套方案实现的成本和速度，考虑到对未来业务变化的灵活支持，同时为了避免影响核心CRM业务的稳定性，CTO决定采用方案一，让两个系统各自聚焦，互相独立，边界清晰，虽然无形中增加了公司应用架构的复杂性，但可以快速实施支持当前的紧迫业务，并灵活应对未来公司的销售业务变化。
至此，我们已经绘制出一套一般企业的简化版应用架构图，以及一张常见的组织架构图。可以看到，应用系统的建设是根据业务的发展而逐步完善的，每个系统都有独立存在的意义和价值。
3.给架构师的建议
不论是架构师、产品线负责人或某个系统的产品负责人，都要有架构设计的理念和知识，尤其是后端产品经理，必须充分理解企业应用架构的基本概念。这里给出一些针对应用架构设计的建议。
1）系统定位和边界要清晰，对应的业务定位和边界要清晰。一套应用系统的存在，是为了解决某一类业务问题，对应某一个业务板块。如果业务板块或业务单元定义模糊，也会导致对应的应用系统定位混乱。
2）系统要实现松耦合、高内聚 。对外界系统要透明、简单、易理解，与外部系统的接口要简明、扼要、灵活。内部模块高度聚合，粒度越细越不可拆解。
3）易变的、尝试中的新业务要避免影响现有业务的稳定性。对新业务的支持，可以考虑新建独立微小型应用系统，以便避免改造成熟核心系统，影响其稳定性和健壮性。
4）系统之间数据要实现单向流转。系统之间尽量保证单向数据流转，确保数据流可回溯性、一致性和可追溯性。混乱的数据流转管理会造成应用架构管理的灾难。
5）架构设计核心目标是支持业务，有时候不合理的存在是合理的。应用架构存在的首要目标是支持业务，很多成长型企业或初创公司面对生存的压力，不能为了保证架构的合理性而拖延系统实施速度而导致企业错过发展时机。这种情况在互联网型企业更为常见。业务还在试错期，系统需要尽快保证支持业务试错，如果一上来就谈论整体架构的合理性，很可能花费巨大成本实现了合理架构后，新业务已经取消或失败。优秀的架构师和CTO要懂得在合理架构设计和灵活多变的业务发展之间做出智慧的权衡取舍。
对于CTO或公司架构师而言，要保证整体企业应用架构的合理性，只要大框架合理，局部的偏差可以忽略，修正的成本也比较小。如果大框架有偏差，修正的代价会非常高。对于产品线负责人而言，要保证局部框架的合理性，避免出现由于设计不合理造成的返工和补救工作。很多时候架构师或产品线负责人要做出判断，是做一套新系统还是修改老系统，若是前者则新系统如何定位，若是后者则老系统如何调整定位。另外还考虑：数据如何流转，系统之间如何关联，底层数据如何打通；是否要复用其他系统模块，是否要将某些模块抽象化、服务化、平台化。对于产品经理，要在系统级别的粒度做出类似问题的判断，能够识别出可能存在的系统演变风险，及时升级控制不了的问题，进而避免做出错误决策。
5.4.6 架构师分类
在软件生命周期拆分树中，软件架构师本身的业务也会涉及架构拆分，拆分出不同位置的架构师就有了各自不同的架构范围：有负责部署架构的架构师，如系统架构师；有负责数据架构的架构师，如数据架构师；有负责应用代码编写架构的架构师，如应用架构师。
1.硬件架构师
硬件架构师的工作职责包括：
·自主服务器硬件系统的架构设计及研发工作；
·承担从业务向技术转换的桥梁作用；
·协助制定项目计划和控制项目进度；
·辅助并督导上游ODM/OEM开展设计工作；
·负责建立适合需求的服务器硬件质量标准及检测流程体系；
·负责组织重大项目技术研究和攻关工作；
·负责带领公司内部员工研究与项目相关的新技术。
硬件架构师负责辅助并指导基于需求的硬件架构设计工作，需要针对不同的业务需求选择合适的技术路线，制定最优的技术解决方案。
2.数据架构师
数据架构师负责制定数据标准、应用标准、运维标准，设计数据标准和模型管理流程，整理数据需求并为建模人员提供支持。其工作职责可以包括以下内容：
·研究与跟踪大数据新技术发展方向，主持制定大数据平台技术发展战略规划；
·负责ODS以及数据仓库逻辑模型、物理模型的分析与设计，并与团队共同制定核心模型的演进路线；
·负责数据仓库的业务探索（Business Discovery）及信息探索（Information Discovery）的工作；
·负责数据平台的设计、开发、维护与优化，不断创新，满足上层数据运营体系各项需求；
·审核数据平台项目总体技术方案，对各项目进行质量评估；
·参与应用分析系统的系统分析、设计以及实施工作。
3.应用架构师
应用架构是从业务到IT转换的第一步。应用是对（系统）能力的分组，实现业务功能并且管理数据。应用架构描述这些应用之间的结构和逻辑关系，应用架构设计的一条重要原则是技术中立，也就是说应用最好是技术无关的。同样的，技术架构是描述支撑应用的技术实现的架构，比如技术标准、平台架构的设计、硬件基础设施的架构设计（比如网络拓扑）、系统请求响应的处理过程等。应用架构师必须是业务专家，直接承接从业务到IT的转换。应用架构师是否能做技术协调管理就要看分工和能力了。
应用架构师的职责不同于网络架构师，网络架构师“不求有功，但求无过”。应用架构师架构的目的是直接为企业创造价值，为企业发展提供动力，提高管理水平。因此，应用架构师在进行架构时要充分理解用户的需求，准确定义用户的需求，通过与用户交流从而为他们开发综合的解决方案。应用架构师在架构过程中会在不同程度上影响人员、流程和技术，一旦他开始进行架构的构建，就是在创造一种环境和条件，让流程更加有效、高速和符合用户的需求。如果说CIO的工作是一个从无到有的过程的话，那么应用架构师就是一个从有到优的过程，要通过统一的规划管理使企业的IT资源发挥更大的价值。
4.系统架构师
系统架构师是一个最终确认和评估系统需求、给出开发规范、搭建系统实现的核心框架、澄清技术细节、扫清主要难点的技术人员，主要着眼于系统的“技术实现”。因此他应该是特定的开发平台、语言、工具的大师，对常见应用场景能马上给出最恰当的解决方案，同时要对所属的开发团队有足够的了解，能够评估自己的团队实现特定的功能需求需要的代价。系统架构师负责设计系统整体架构，从需求到设计的每个细节都要考虑到，把握整个项目，使设计的项目尽量效率高、开发容易、维护方便、升级简单等。
系统架构师负责提供运营支撑软件应用的信息系统的结构设计，一般以满足各种非功能性需求或运营性需求为设计目标（如安全性、可伸缩性、可互操作性等）。
5.4.7 如何拆分
1.代码拆分
在代码层面，要对业务代码和访问代码做好架构拆分。业务代码是软件访问生命周期的核心，软件运行的拆分受限于软件代码的拆分。因此要确保业务代码符合业务的生命周期，使得业务生命周期活动的结果积累在生命周期的主体上，也就是内聚性，避免散落到访问代码中。这样软件的拆分就不会有太大的问题。
2.架构拆分
系统发布之后，需要由一套统一的组件来解决分布式带来的共性技术问题。比如提供服务的发展机制、提供服务的分组路由机制、同机房优先机制等，这些能力沉淀在了一个叫HSF的框架里。为了解决单库性能瓶颈问题，使用了分库分表的技术，这个技术被沉淀在了TDDL框架上面。为了解决分布式事务的性能问题，把原本一个事务里的工作拆成了异步执行，同时必须保证最终数据的一致性，我们采用了消息发布订阅的方式来解决，这个消息框架就是Notify。
通过采用分布式中间件，有效地解决了应用分布式后带来的技术扩展性问题，同时让整个系统的技术架构变得如当初一样简单。如果系统计算能力不够，基本上能做到只增加服务器即可。共享服务层和分布式中间件使频繁的业务变化被封闭在了一个适合的系统层，同时技术的变化也被隔离在了一个合适的范围。
5.4.8 一些案例
要想使用开源技术，就要理解开源技术都有哪些特定的使用场景，采用之前必须了解这些技术原本是用来解决谁的问题的。如果不先搞清楚就使用这些新技术，很有可能会导致更高的研发成本。小流量的公司采用针对大流量的新技术，仅仅维护和监控就足够让人头疼。如果环境配置跟不上，则技术是无法发挥作用的。新技术最重要的配置就是人的配置，以及人的观念的配置。
作为开源技术的使用者，要掌握作者的理念，一般要先从理解作者面对的问题入手，也就是从业务入手，分析作者是如何拆分业务生命周期的。从这个角度来说，看代码和看书没有区别。
1.数据共享
为了解决业务扩展性问题，首先需要建立共享服务层，把公共的业务元素抽离出来形成共享服务。
在2008年，天猫和淘宝网是互相独立的两套系统，天猫有自己独立的成员、商品、交易、店铺、优惠积分等系统，唯一和淘宝共享的是会员数据。在天猫运行半年之后，由于数据和系统的独立，很难方便快速地借力淘宝网的大流量，这不符合互联网时代业务快速变化的特性，所以需要彻底打通淘宝网和天猫的数据和系统。
“房子千奇百怪，但是砖头都是一样的。”利用共享服务层解决了业务扩展性问题，好处是新构建一个业务市场变得非常容易和迅速，同时任何数据结构的变化只需在一个地方改动。带来的挑战是系统采用分布式之后研发要关注分布式本身。我们希望研发人员仍然像之前开发单机版的软件一样开发系统，把分布式的问题控制在一些通用的组件里面。这就需要引入分布式问题的中间件技术。
2.共享服务
共享服务层的建立为横向业务提供了统一的数据和服务收口，比如手机、安全、商家服务这三个横向的业务就非常依赖共享服务。
各个共享服务之间形成了比较好的隔离，保障了各个共享服务独立的发展空间，各个共享服务既互相关联，同时又互相独立。架构的域之间低耦合、高内聚。因为隔离做得比较好，没有业务之间的复杂交错，所以各个业务领域发展创新不受限。最佳案例是早期支付逐步发展成为支付宝，物流域逐步发展成为菜鸟物流。
3.服务宕机
很多时候，业务需要跨公网调用一个第三方服务提供的接口，为了避免每个调用方都依赖于第三方服务，往往会抽象出一个服务：
·解除调用方与第三方接口的耦合；
·当第三方的接口变动时，只针对服务进行修改，而不是所有调用方均修改。
此时接口调用流程是什么样的呢？
由上图所知：
1）业务调用方调用内部service；
2）内部service跨公网调用第三方接口；
3）第三方接口返回结果给内部service；
4）内部service返回结果给业务调用方。
这个过程存在什么潜在的大坑呢？
