读《架构真经》-互联网企业CTO的秘籍

作者：童继龙 来源：继龙书享汇

长期以来，软件工程师们在向架构师角色转换的过程中，一直找不到具体的抓手，没有办法找到新角色的突破口，往往是看着各大公司分享出来的PPT，赞叹着这些架构设计的精妙和实用，忍不住生出一阵阵的佩服敬仰之情，一旦开始设计自己项目的架构，却不知道如何下手，怎么开始思考。有没有一些符合CTO或是架构师们使用的基本原则，可以去给予初任架构师的解决困惑的呢？由前eBay、PayPal公司的CTO联合撰写的《架构真经》从很大程度上就解决这了个问题。

说实话自己离开技术领域已经许多年了，对于技术性特别强的知识面涉及的也越来越少了偏向于商业、管理、财务类的知识学习更多一些，但《架构即未来》、《架构真经》这两本书是我最近一段时间细读的内容。主要还是在于思考几个核心问题：

1、对于明源的客户房地产开发企业，从传统地产开发业务纷纷转向多元化发展的时候，从单一的地产信息化管理系统应用转向“多速率IT系统”（稳类的管控类系统、敏态的场景类应用）变化时，从技术架构视角来看会有哪些挑战和变化，明源是否能够跟的上行业客户商业战略变化带来的信息化、 数字化需求变化？

2、对于阿里巴巴为代表的BAT企业都纷纷提出2B领域的“产业互联网”是下半场，那如何充分理解阿里的“中台战略”对于产业互联网下半场的价值？

3、作为曾经的IT技术领域从业者，深深地知道技术架构对于IT或是互联网应用的价值（或是影响程度），这就如同地产&建筑行业的设计师都知道“结构”代表了真正的产品能力！入行不久或是研究不深的技术人员会问：你们公司的产品用的是.NET还是JAVA/PHP开发的呢？其实选择什么样的开发工具在云计算的时代早已经不是关键问题了，在运行平台上往往都会基于Docker技术（以Linux平台为主），即便是微软也主动推出了.Net Core用于支持.Net开发技术可以平稳运行于Linux与Docker平台，当然也是为了能够让自己的应用更好地兼容云计算平台（如微软自家的Azure或是阿里云）。

大约两周前与一家客户的CTO交流技术方案，在探讨的过程中提出一个非常关键问题：你们都有哪些技术架构设计的基本原则，这些基本原则背后所遵从的商业逻辑是什么？对的，技术架构的选择永远都有“商业逻辑”在背后做支撑，无论是甲方企业（如BAT自家的架构师）还是乙方企业（如SAP、用友、明源等这样的IT企业）本质上来说都是要基于商业的本质--“效率”这个硬性约束条件来做技术架构规划、产品规划&设计的。

回到《架构真经》这本书中的核心内容，提出了互联网应用架构设计的50条原则，而这50条原则都是基于“风险收益模型”来做IT系统架构可扩展性讨论的基础。我们对什么对架构背后的可扩展性这么感兴趣，这是我们想要有高度可靠和可用的（对某些特定或隐含的服务质量指标）产品或服务（即使在中等到极端的条件下增长），这就是为什么要要投资架构领域使产品可以具备可扩展能力的根本。如果对应用需求增加会对产品可用性或服务质量发生什么影响不感兴趣，那么我们不会对试图扩展有兴趣（如某些部门如果对于客户不太关心，不在意人们在需求高峰期排队等待数小时的话就不会在意）。但对于企业来说往往没有相应的垄断性，因此必须要关注可用性和可扩展性。

对于可用性和可扩展性方面的关注也代表了我们的风险观，也更是代表了一家企业为客户提供服务的水准（SLA），在IT领域我们往往可以把风险定义为“问题发生的概率”X“影响”。影响又可以进一步包含影响的百分比、停机时间、数据损失的百分比、受影响的响应时间等要素。对于IT系统依赖越来越大的企业，如电商企业对于平台的高可用性是100%的依赖，一旦失去系统的可用性时，那就会出现让企业猛受灭顶之灾的打击。

那如果要去构建高可用、高性能IT系统，会从哪些视角来考虑呢？《架构真经》这本书中做了一些特别的说明，与大家分享：

1、大道至简：任何IT系统过于复杂，使用了太多“中看不中用”的技术导致了过度的复杂性，从而系统从建设一开始的时候就埋下了崩溃的隐患。这个主题从讨论了防止复杂性（规则1），以及从初始需求或历史沿革开始简化产品直到最终实施的 每一步（规则3），所得到的产品从技术角度来看容易理解，因此也容易扩展。如果尽早考虑扩展（规则2），即使不实施，我们仍然可以根据业务的需要做好解决方案。规则4和规则5则教导我们通过减少对象的数量和减少下载对象所必需的域名解析，来减少浏览器必须完成的工作。规则6教导我们要保持网络的简单和同构，以减少混合网络设备可能引起的可扩展性和可用性问题（可见，可扩展性和可用性不仅仅是一个软件开发与实现的问题）。

2、分而治之：作者认为使用三个简单的规则就可以助你的扩展所向无敌。沿着X、Y和Z轴的扩展都各有优势。从软件设计和研发的角度考虑，通常X轴扩展的成本最低，Y和Z轴的扩展方案的设计有点儿挑战性，但有更多的灵活性，可以进一步拆分服务、客户甚至技术团队。三个方向的扩展：

1）X轴通过克隆扩展：通过克隆或是COPY数据和服务使你很容易地扩展事务。

2）Y轴通过拆分不同的东西来扩展：通过名词或动词标识来拆分数据和服务，如果正确完成，可以有效地扩展事务和数据集。

3）Z轴通过拆分类似的东西来扩展：通常是客户数据集。依据客户属性拆分客户数据，形成独特和隔离的数据分片或泳道，以实现事务和数据的扩展。

3、水平扩展：对于向上扩展是中慢速增长公司的选择，但那些增长速度持续超过摩尔定律的公司，将会在毫不知情的情况下，突然发现自己所拥有的高端昂贵的系统的计算能力遭遇了极限。我们见过几乎所有影响大的服务故障都是同一个原因，产品自以为 “了不起”。我们相信，提前做好扩展计划，以便在需求出现的时候可以轻松地拆分系统是明智的。按照我们的规则扩展系统和数据中心，利用云计算来处理意外需求，依靠廉价的商品化硬件，为超高速成长做好准备！

4、先利其器：使用合适的工具来完成工作在任何学科中都是非常重要的。正如大家不想见到管道工只带一把锤子到你家修理管道一样，客户和投资者也不希望你带着单一的工具来解决有不同特点和要求的各种问题。汇集各团队的不同解决方案，以避免落入马斯洛锤子的陷阱。当然这里也有一个忠告：引进每项新技术都需要另外一种技能来支持。尽管工作中使用合适的工具很重要，但不要过度强调专业化，以至于没有足够深度的技能来支持。

5、画龙点睛：本章提出了三个原则（避免画蛇添足、停止重定向、放宽约束时间）来应对可能会限制系统扩展能力的决定。从不复查工作开始。购置昻贵的数据库和硬件以确保系统正确地记录事务和事件。不要指望它们能够不停地工作。重定向需求司空见惯，但过度使用该工具会导致从用体验到搜索引擎等各种问题，阻止重定向泛滥失控。最后，考虑系统的业务需求，商品和对象的时间约束，使系统成本昻贵且难以扩展。

当然，还有许多原则，如缓存为王（CDN加速）、前车之鉴（事故复盘）、重中之重（数据库扩展规则）、有备无患（故障隔离、避免系统串联、拒绝单点故障等）、异步通讯（通讯首选方案）等没有来的及展开细说，如果感兴趣的话可以阅读原书！