【SDCC 2015现场】唯品会首席架构师蔡学镛：从三维的角度看软件系统架构

【CSDN现场报道】2015年11月19-21日，由CSDN重磅打造的“ 2015 中国软件开发者大会 ” （以下简称SDCC 2015）在北京朗丽兹西山花园酒店隆重召开。今年是第七届，大会为期三天，除了阵容强大的全体大会外，主办方还精心筹备了九大技术专场论坛，包括：架构实践论坛、前端开发论坛、数据库实战论坛、研发管理论坛、安全技术论坛、算法实战论坛、编程语言论坛、产品与设计论坛、微信开发论坛。此外，还有五场特色活动及展览展示。

2015中国软件开发者大会首日的全体大会上，来自唯品会首席架构师蔡学镛做了题为《从三维的角度看软件系统架构》的主题分享。蔡学镛全面解读了3D架构和精华摘要，及消息驱动框架设计经验分享。他认为软件系统架构可以分为：外部系统、架构不规范系统、架构规范系统，以及分析了他的开发方法：设计界面层、设计应用层接口、设计整体架构、设计服务层子系统接口、设计资源层子系统接口、设计数据模型。

唯品会首席架构师蔡学镛

以下为现场速记整理：

我是唯品会的首席架构师，我过去这几年我从杭州、北京、上海深圳到现在广州也去了，我把这5个IT重镇都去全了。广州对我来说有一个感触，是这个地方好像大家都讲广东话，跟别的城市不太一样，在这个地方不会讲广东话是一个异类，我在任何一个地方买东西都被认为是异类。

我认为架构是三个维度的，我们从三个方面看架构才会比较完整，我的系统我分为三类，黑色的代表是黑盒子，是我们不能掌握对内部不清楚的系统，我们通过接口调用。灰色的是我们自己的系统，在我们的机房里比较老旧，我们对内部不是特别了解，也没有办法整改它。白色的系统是我们自己开发出来规范的系统，我对规范的系统里划分了四层，分别用四个颜色来表示！我这边分了S轴和Y轴，S轴是四个彩色！Y轴是系统轴，Y轴往下是正的，在正的地方我们放的是我们开发的白色的系统，在Y轴的地方放的是我们外面相关的系统，或者是旧的系统，或者这些灰色的系统，以这边的例子来说，我们想调用明年的系统不是我们能控制的。我们买了某一家公司的CIN，它是架构不规范的系统，我们很规范的开发了订单系统和支付系统。

Y轴每个系统都可以分成四层，有一些层次大家比较罗嗦一点，我后来简化为四层，分别用红色、橙色、绿色和紫色来表示！X轴分七层，我们来看四层的，第一层是前端层，在用户电脑上执行，和用户交互的功能。它最多只能够展现逻辑，没有业务逻辑在里面而且能够在用户的手上运行的代码，我们对它的安全也是要存一点疑虑，里面不能放太多的东西。第二是应用层，在服务器上执行，通过前端的应用转发给后端，逻辑非常少，只是简单的判断，大部分事情是转发后面的服务层的API来完成的。绿色的服务层是最关键的一层，全部的业务逻辑都在这里面，以服务接口的模式报出来，他所暴露出来的接口给前端用的话，这个接口就是API。服务层如果暴露出来的应用层调用的就是API。最后一层是资源层，包含三大类，一类是我们内部数据的服务器，第二类是灰色的系统，第三类是黑色的系统。我们内部数据服务器我又简单大略的分为六类，分别是看到圆柱体这是数据库，还有一个缓存和文件服务器和对话Session服务器，还有消息队列和CDN。这八类是资源层里面的资源。这四层的分类没有很特别。

我们所开发出来的订单系统里这四层都个别有子系统，有一个红色的子系统一个橙色和绿色的子系统，而且有两个紫色的子系统，其中一个紫色是Session服务器，其中一个是数据服务器。它只有一个绿色的服务器子系统和紫色的资源子系统。刚才看了这样的分层方式，里面有一个重要的原则，前端和资源层是有状态的，中间这两层我们尽量让它没有状态，而且我们知道系统没有状态的话，未来应用比较容易。

正常的情况我们不允许跨层调用的，为什么让它可以跨层调用呢？它不是跨层调用的关系，是快速反应的关系，红色有可能访问CDN，不用走原来的路径，不用去老改服务器。这个橙色的有一个箭头到最后的紫色，因为有可能要去存它的绘画状态，所以就需要有这个箭头。虽然说分层为一个结构，但是不完全是传统的所谓的分层，我这边没有这样的原则。

每一层比较特别的是他们都可以跟资源服务器发生关系，可以跟哪些资源服务器发生关系呢？资源服务器分为八类，6个是紫色的，一个灰色一个黑色，总共8个。我所做的限制是这样的。前端层可以去访问文件服务器，可以访问CDN。另外可以访问后面这个应用层的服务器了。应用层主要是访问缓存和文件服务器，但是主要是Session服务器。资源层最终包装调用Y轴地方的灰色和黑色的系统。很简单的来看，系统和系统之间是这样的调动关系，如果两个系统之间互相调用的话，有一个系统想调用我们系统，只能从1或者2的路进来，只能访我们的服务或者我们的资源，我们要有权限控制的。我们访问别人的系统也有两条路径可以出去，你可以通过应用层去访问3，或者通过绿色的服务访问4，外面的服务器。你对外访问到底从1还是2进来要看当时的状况，我现在的规范整个系统架构是非常清晰的，不会有太大的麻烦出现。系统跟系统之间有两类关系，一个是串联一个是并联，这一页是并联，假设橙色的应用同时要展现用户的合作消息和数据，又要在这个页面上展现广告，所以橙色的子系统会同时调用到用户服务系统和另外系统里面的广告。A和B这两个服务子系统是并联的关系。

现在看串联的关系，你这边有两个服务，一个是用户服务一个是用户核心服务，如果放的是用户比较关心的数据，用户核心的数据、姓名、身份证号都不会变动的，你放在用户核心系统里，还有一些附加的信息，电话、地址都可以放在用户系统里，你最后把用户核心系统包起来就希望了串联的关系。接口从A这个系统暴露出来，用户核心就不暴露API了。这个是串联的设计方式。

再来看并联的设计方式，订单系统同时会用到商品系统和订单系统，这两个服务子系统，如果就从订单和商品来看是串联，从定单和用户来看也是串联，但是商品和用户来看是并联关系。第一个是两个服务系统功能要彼此独立，需要的时候我们尽量让他用并联调用，这是比较推荐的。第二，如果你是功能扩展的方式，或者有一个旧的系统你想把它包起来就用串联的方式。第三，多用串联。但是串联如果太长的话，任何一个环节出问题都可能影响到整个系统的稳定，而且太长了，整个反馈的时间也会拖长了，我们多用并联少用串联。

刚才介绍了X和Y轴，X是四层，从用户到用户资源的四层。Y轴是系统轴，有一个一个的系统。接下来是Z轴，从开发、打包、部署到中间件、操作系统、虚拟硬件和物理硬件这样的关系。开发者关心的部分放在Z轴的地方。运维人关系放在Z轴的地方。我就把原本向下的Y斜一个角度，如果你做完X跟Y的开发你是一个应用架构师，你是比较偏业务方面的应用架构师，你做了X跟Y的设计开始开发了以后最后结果会经过开发打包和部署，接下来是运维的人员，运维关心的是另外的维度，是黄色的部分。这边包括高并发、高可用在这个地方考虑才比较强大。一开始考虑并不是正确的时机，一开始要业务的模块咱们切割？才能让业务避免重复，这才是一开始应该关心的重点。跟现在敏捷的开发已经彻底开发了传统的开发方式，现在大家都是稀里糊涂的开发出来，后来很难去维护了。

在最下面的两层我分为虚拟层和物理层，如果你部署在云平台上面的话，最下面的一层是IAAS，中间件和操作系统我们可以称之为平台。所以这就是平台的部分，如果你在云平台上部署平台的话，就是PAS平台。讲到云平台和IAS和PAS你们会想到下一个是什么？是SAAS！主办单位让我讲干货，我不能讲自己非常的快乐，也不太好。SAAS要在X轴上找，所谓的SAAS是对方把他的软件开发好放在服务器上，你电脑不需要安装任何的软件，你只需要浏览器输入IP就可以使用。其实应该在X轴上找SAAS。如果X轴前面的两层用wep形式开发的话，我们就说这是一个SAAS的系统。

接下来看开放平台了，开放平台在这个位置，刚刚提到橙色是应用，应用怎么开发出来的？叫绿色的ATI，甚至是API，你这个API不只是你们公司的人，而且也对外开放了，你服务系统的API就是开放的平台。如果你们公司不只是一个系统有开放API而是一堆系统都开放API，我尝试把里面很多的系统都开放API，整个平安都是跟金融相关的，有银行有基金、各种保险理财都是跟金融相关的，这样的情况我们就可以把开放的API统称为开放平台，这是有一个领域的，是互联网金融的开放平台。那就没有那么孤单了，它不再是一组API而已。

最后讲的大数据，关系的是最后的一层，虽然说大数据还是有很多种不同的说法，我们对用户操作过程中的反馈，他点击的按纽点击几秒也算，我现在讲的稍微传统一点，我们最终操作过以后沉淀下来的数据的结果。最重要的是刚刚提到的数据是非常关键的，数据包括资源，为什么我用资源而不用数据这个词呢？资源涵盖的比数据更广，包括对外接口也是你的资源，数据的读写非常重要，可以篡改你的数据还得了！过去我们常用的保护的方法有什么？有ACL、基于角色的，你赋予某个人什么角色？有什么权限？这两种是大家常用的方法！现在美国开始推广ABAC，这个东西可以去搜索一下，美国的联邦政府前面都在推行ABAC了！

我今天尽量讲比较偏上层的部分，有了X和Y的架构模型之后，当你的用户踢皮球给你，希望你把这些东西转成软件，我们可以把需求一个个转成符合我刚才讲的架构。我分为六个步骤，第一是：设计界面层。从前往后设计。我这个方法是从BDB学来的。所以先设计界面，先把图像画好，大家知道界面有哪些功能就可以分析出有哪些接口。然后分析架构长什么样子，然后是资源层提供什么样的接口，最后再把数据模型整理出来！接下来有实际的例子跟各位演示。如果有人跟你提了需求，希望你提出的系统让用户做注册，你必须教会用户界面，输入ID密码，要输入两次，姓名和电话是必要的，最后按OK，包括ID被别人用过了，包括密码两次都不一致。成功的话就到下面的画面，输入短信的验证码，要输入成功验证你的电话确实是你输入的电话，如果验证码输入失败，你有三次机会再去输入。经过这个分析，你可以分析出应用层需要提供哪些接口了。查验两次输入密码是否一致？不需要传给后面应用！这个检查逻辑不需要应用层提供接口。第二，查验是否有字段为空，不需要应用提供接口。第三，检查ID与电话是否已经存在？一定要调用到后面的应用接口！最终才能捞出这个数据，确定没有被人用过。最后是错误的时候要传回错误码，经过简单的分析我们就知道应用层应该提供哪些接口了！交互过程中你要存一下数据，但是不至于沉淀到最终数据库，你要存到哪呢？这就是Session状态。这个不用输入到数据库！你要产生短信验证码这是一个乱码，到底是1234还是5678？是什么号码？由谁产生的呢？用户输入你要做一个比对，谁产生的？存在什么地方？这个也是放在Session，放在数据库没有意义。数据库尽量放关键的数据。这两个东西都要放到Session。

你做第一个架构的设计。你设计的注册界面是注册的应用，需要提供注册的接口之外还要后面的注册服务。它如果验证码是由乱数产生的，就必须存到Session服务器。这个设计就不好了，我不允许服务子系统去连Session，因为我认为这样的设计是有瑕疵的，我只允许应用子系统去连Session，所以这个设计就否掉了！我们看第二个设计；我让注册应用他自己去短信服务来去做发验证码，以及检查验证码的功能，短信服务来负责做这个事情，我就不用管了！而且刚刚是串联，这个是并联，还是稍微好一点的。而且这样子你们发现少了一个Session服务器，你就不需要Session服务器了。你就是注册服务就不需要连Session服务器了。

第三，前面有一个短信服务的服务子系统，做事情非常少，我们电信公司提供的系统我们会做简单的包装，已经包装成服务了。所以你经由这样的分析，就可以把比较好的架构设计出来，你就可以继续往后面，服务层该提供什么样的接口？一层层往后面递延，大家各自开发符合这个系统规范的接口就可以并行的开发了。以前我不怎么关注事务，但是传统的应用里事务是很重要的！用户跟应用之间有很多的request和business业务上的事务，我没有办法讲的太细不过你们可以去搜一下Session的差异。

最后是资源，你去访问这个UIO，你只要做这样的设计，接口设计就行了。具体数据要接下来，要有另外一组数据相关的专家，它通过这些接口的访问来做分析，可以了解原来这个数据的访问量非常的高，我或许应该为它加一个缓存，这个数据经常写，所以不能用缓存，原来这两个数据经常一起出现，所以我应该把他们放在一起，访问会比较快。这些都有可能一开始你没有办法得知，而是通过数据访问和分析才有办法知道，所以你要设计的比较有弹性，通过接口的方式来访问，而不暴露具体数据库的结构的话，后面做这个弹性就比较有可能了！后面因为也许的状况，某一些数据放到COLUMN，这边我列出21个数据的指标，大部分通过接口访问的统计得知，只有前面这6个我划上星号的是没有办法的，第一个数据的重要性有多重要？它丢了是不是我们人头落地了？你在银行，这个用户存多少钱？你都搞不清楚，这个重要性非常高。保密性都必须业务人员具体的做指定，还有唯一性和访问费用的成本！你调用接口是要花成本的，莫名其妙的成本就多了，铁路的时刻如果不是经常变的话，你可以保存起来。如果他是VIP用户，你是一般用户，你或许可以放在同一个表里面，当这个系统不堪负荷的时候你要服务你顶级的客户，到底有没有分级呢？是怎么个分级法呢？我们这里做21个指标，如果各位对数据库比较专精的话还可以找出更多的指标。今天就是这样的内容！

更多精彩内容，请关注新浪微博：@CSDN、图文直播专题： 2015中国软件开发者大会 。