系统架构设计师

系统架构设计师-论文-架构风格

前言：

这三个月由于工作等方面的事情，所以没有更新博客。

其实我是有做许多总结的。但是写博客，就需要整理格式，好麻烦啊。。。。

不过接下来，我会慢慢整理出来的，包括java，spring，数据库，业务架构等。

四个月，通过工作之余的学习，今天终于将架构师的证书拿到手了。然后想到我可以将架构师的论文发上来。

首先谈谈架构师考试的论文通用问题，分别是素材（包括实践与理论），心态，技巧。

本人是不提倡押题的，但是素材的准备是必要的。素材包含两个部分，第一是挑一个你熟悉并且适合的项目。熟悉是指你要了解这个项目的功能，技术要点，开发背景等。而适合是指项目属于商业项目（不是什么图书管理系统那样的学习项目），并且便于在多个论文题目中使用（这个项目可以谈架构，也可以谈需求什么的）。第二是理论知识的充分准备。需要熟悉多个方面的论文理论知识，包括架构，需求，数据库等方面相关的理论储备。

论文准备最重要的是心态。因为题目是不固定的，每年都有新鲜的技术考察，所以我们需要稳定的心态，来不变应万变。拿我自己举个例子吧。我之前由于时间关系，实际写出来的论文，只写了三篇（当然我做了五篇论文的理论素材）。实际考试时，我发现没有我写过的论文。唯一能写出较为完整的论文理论的是微服务方面，所以我在慎重思考了两分钟后，我将原来有关架构风格的论文迅速转为微服务方面的论文，最后通过了考试。

架构师考试的论文技巧，其实准确说是论文的格式，就像毕业论文也有其格式要求。说实话，论文如果有可能的话，最好还是让专业的人批改一下。无论你是通过培训班，培训老师，又或者是让一些学员帮你提交，提交两篇论文，心里会有底气一些。论文技巧，就是内容的分布要合理。一篇论文一般会有三个论点，其中会有一个核心论点。另外两个论点往往分别一个段落即可，而核心论点往往需要五个段落（相关理论一段，中心要点一段，分要点三段）。除了这六个段落，正文还有背景介绍一段，总结一段。最后，别忘了还有一个摘要，摘要建议最后写。

通用方面主要就这三个方面，如果还有什么需要问的，可以@我。

架构方面的知识作为系统架构设计师的绝对核心，其知识点几乎占到整个架构师考试的一半。而架构方面的论文，可以说每年都有，所以是必须准备的。

一，理论：

二，论文：

摘要：

本人于2015年11月参与浙江省某在线教育平台“外教一对一在线教育”项目，该项目为客户提供了一对一欧美外教视频教学，社交圈，公众直播等功能提供全方位的软件支撑，在该项目组中我担任系统架构师岗位，主要负责整体架构设计与中间件选型。本文以该教育平台为例，主要讨论了软件架构风格在该项目中的具体应用。整个系统采用具有三层的层次式软件架构的设计思想，分别是应用层，服务层，数据层。在应用层中的业务逻辑层的设计中，将整个业务系统划分为十余个子系统。服务层以dubbo服务框架为核心，数据采用了Mybatis框架。整个系统开发工作历时18个月。目前，该系统已经稳定运行近一年半的时间。实践证明，这种架构设计有效地降低了维护成本，提高了系统的开放性，可拓展性，可复用性和可移植性。

正文：

随着国家对教育对越发重视，英语教育的市场份额逐步上升，其中用户口语提升的需求越来越大。为此，一些公司开始提供与外国人聊天的平台。我公司决定从国际通讯领域进军口语教育领域。为了这项战略转变，公司于2015年11月设计在线教育平台系统（以下简称为“系统“）。该系统帮助人们与欧美外教进行面对面的口语交流与教学。其中随意聊提供了一个类似QQ视频通话，而正式课程还提供了H5互动课件以提高教学质量。与此同时，还有公众直播用于拉新，AI测试用于评测学员能力，降低成本。我参与了该项目的开发工作，担任系统架构设计师职务，主要负责设计系统架构。本项目组全体成员共9人，我主要负责项目计划制定，需求分析，整体架构设计与技术选型，以及底层设计。该项目的架构工作于次年2月完成，整个项目耗时18个月，于2017年5月完成。

在架构工作的开始阶段，我们便意识到，架构风格定义了用于描述系统的术语表和一组指导构建系统的规则，是系统组织方式的惯用模式，可以为我们的项目提供架构级的通用解决方案。这种架构级的软件重用可以极大提高我们的系统建设进程。软件系统开发中常用的软件架构风格有数据流风格，调用/返回风格，独立构件风格，虚拟机风格，仓库风格。数据流风格包括批处理序列与管道-过滤器，其每一步处理都是独立，顺序执行的，适用于简单的线性流程。调用/返回风格包括主程序/子程序风格，面向对象风格，层次结构风格，其进一步降低系统耦合度，明确系统层次。独立构件风格包括进程通信，事件驱动系统（隐式调用），其构件特点为软件重用提供了支持。虚拟机风格包括解释器风格，基于规则的系统风格，其具有良好灵活性，可自定义规则。仓库风格包括数据库系统风格，超文本系统风格，黑板系统风格，其以数据为中心。除此之外，还有dssa，soa等架构风格。

在了解需求后，我们决定在公司技术顾问的建议下，采用层次架构风格。为了解决公司原通讯系统代码冗余问题，我们进行了系统服务化，中间层不同的服务中心提供不同的业务服务。最终，我们将系统分为应用层，服务层，数据层。应用层负责具体业务和视图展示，如网站首页，app内搜索输入与结果展示等，其又分为视图层与业务逻辑层。服务层负责为应用层提供通用服务支持，如账户管理服务，session管理服务等，其又细分为逻辑处理层与数据接口层。而数据层负责提供数据存储访问服务，如数据库服务，缓存服务，文件服务，搜索服务等。接下来，我将分层次详细介绍三层层次体系结构的设计过程。

首先是应用层。在应用层中，我们将系统根据应用进行水平划分，这有助于代码管理与维护。我们将系统分为课件管理系统，公众直播系统，学员测试系统，课程管理系统等十余个子系统，这里以课件管理系统为例。课件管理系统负责学员上课所用的课件，有课件编辑，课件预览，课件交互，课件展示等多个功能模块。功能模块调用服务层的服务支撑，如课件交互需要调用服务层由ActiveMQ实现的stomp通信服务，通过该通信服务，实现教师端与学生端的课件的同步，从而使得课件交互变得有趣，生动，具有互动性。另一方面为了区别教师端与学生端的交互权限，课件模块还需要调用服务层的账户服务，确定用户身份，从而明确用户在课件交互中的交互权限。与此同时，为提高课件的可修改性，可互动性等，课件采用H5编写。应用层主要采用structs这一基于J2EE平台的MVC框架，主要通过Servlet与JSP技术实现。另外还有动静分离，动态资源静态化等，这里不再赘述。

其次是服务层。服务层采用了dubbo服务框架等技术实现。随着服务器规模的扩大，开发人员的增多，每个应用都变得复杂，臃肿，存在大量代码重复。为解决这个问题，提出了两个方案。一个是将应用拆分得更小，确保每个应用都保持在一个合适的大小。好处是设计能够较快地完成，代码也较容易实现。这个方案存在一些问题，一方面数据库的连接数压力依旧存在，另一方面，代码的冗余依旧存在。所以我们采用了第二个方案-服务化方案。服务化方案，即应用层和数据层中增加一个服务层。首先从结构上来看，系统结构更为清晰明了，更为立体。稳定性上来看，许多散落的代码成为了通用服务，并交付专门的团队负责运维。出于对成本与技术成熟度的考虑，我们采用了阿里研发的dubbo服务框架。在服务框架实际操作时有两个问题：服务框架自身的部署方式问题与实现服务框架所依赖的一些外部jar包与应用自身依赖的jar包之间的冲突。前者，我们通过Tomcat作为Web容器，而服务框架作为容器的一部分。后者，我们通过Java的ClassLoader将服务框架自身用的类与应用用的类进行隔离。除此之外，还有服务线程池隔离，分布请求合并，服务调用端的流控处理，异步服务调用，通过Future方式对远程服务调用的优化等问题，限于篇幅，不再赘述。

最后是数据层。数据层涉及缓存，文件系统，数据库，数据通知服务，搜索系统等模块。由于用户对数据的访问具有集中性，所以我们基于SpringCache与Redis实现了缓存机制。由于系统的业务特性，数据库往往是读操作远多于写操作，所以我们对数据库进行了读写分离。数据访问方面，Java已经有很多成熟技术，大致分为三种。第一种是为用户提供专有API，这种方法便于实现功能，但是通用性较差。第二种是通过JDBC方式访问数据库，数据层本身作为一个JDBC的实现，也就是暴露出JDBC的接口给服务层。该方法成本很低，迁移成本也非常低，但开发成本相对高一些。第三种方式是基于ORM或类ORM接口的方式。我们采用的就是这种方式，使用数据库时使用ORM框架-Mybatis框架，再将框架包装一层，用于实现数据层功能，对外暴露的仍然是Mybatis的接口。该方法开发高效，敏捷，成本较低，而且兼容性不错。此外，我们采用solr作为数据层搜索引擎，数据访问层物理部署采用Proxy方式等。限于篇幅，不在赘述。

最终项目成功上线，正常运行了近一年半，收到各方好评。尤其是H5课件的良好互动性，使得大量业界同行争相模仿，改用H5制作课件。还有我们的服务化方案架构被作为许多传统互联网企业系统重构的经典方案。在系统的架构设计中，我们引入了层次架构的设计思想，有效地降低了维护成本，提高了系统的开放性，可扩展性，可重用性以及可移植性。当然还是存在一些问题的。如H5课件采用http协议，易被非法劫持，嵌入广告，可以将协议修改为https来解决。还有我们采用的负载均衡算法是加权轮转算法，过于简单，常常出现资源分配不合理的现象，可以将算法改为加权最小连接数算法来解决。这些都是我在今后的系统设计和开发中需要注意与改进的地方，也是日后我应该努力的方向。

三，总结：

这个论文的项目，其实我不是很熟悉。但是当时这个项目最好接触，体量也足够。囧。

但是总体的技术架构是没有太大问题的，技术点也是没有问题的。

最后的最后，说一个要点，不要抄论文，不要抄论文，不要抄论文。我之所以将我的这篇论文放上来，是为了令你们能够熟悉论文的结构（心疼我当初写论文的时候，网上找不到太多适合的相关博客）。

附录：

早期未修改的论文：

摘要：

本人于2015年11月参与浙江省某在线教育平台“外教一对一在线教育”项目，该项目为客户提供了一对一欧美外教面对面视频教学，以及相关的社交圈，外教公众直播等功能提供全方位的软件支撑，在该项目组中我担任系统架构师岗位，主要负责整体架构设计与中间件选型。本文以该教育平台为例，主要讨论了软件架构风格在该项目中的具体应用。整个系统采用具有四层的层次式软件架构的设计思想，分别是接入层，应用层，服务层，数据层。在应用层中的业务逻辑层的设计中，将整个业务系统划分为十余个子系统。子系统根据其环境与特点采用相同或不同的架构。整个系统开发工作历时18个月。目前，该系统已经稳定运行近一年半的时间。实践证明，这种架构设计有效地降低了维护成本，提高了系统的开放性，可拓展性，可复用性和可移植性。

正文：

随着国家对教育对越发重视，英语教育的市场份额逐步上升，其中用户口语提升的需求越来越大。为此，一些公司开始提供与外国人聊天的平台。我公司决定从国际通讯领域进军口语教育领域。为了这项战略转变，公司于2015年11月设计在线教育平台系统（以下简称为“系统“）。该系统帮助人们可以与欧美外教进行面对面的口语交流与教学。其中随意聊提供了一个类似QQ视频通话，而正式课程还提供了H5互动课件以提高教学质量。与此同时，还有公众直播用于拉新，AI测试用于评测学员能力，降低成本。我参与了该项目的开发工作，担任系统架构设计师职务，主要负责设计系统架构。本项目组全体成员共9人，我主要负责整体架构设计与技术选型，以及底层设计。该项目的架构工作于次年2月完成，整个项目耗时18个月，于2017年5月完成。

在架构工作的开始阶段，我们便意识到，架构风格定义了用于描述系统的术语表和一组指导构建系统的规则，是系统组织方式的惯用模式，可以为我们的项目提供架构级的通用解决方案。这种架构级的软件重用可以极大提高我们的系统建设进程。

了解需求后，我们决定在公司技术顾问的建议下，采用层次架构风格。为了解决公司原通讯系统代码冗余问题，我们进行了系统服务化，中间层不同的服务中心提供不同的业务服务。最终，我们将系统分为接入层，应用层，服务层，数据层。接入层负责应对PC端，移动端等的接入。应用层负责具体业务和视图展示，如网站首页，app内搜索输入与结果展示等，其又分为视图层与业务逻辑层。服务层负责为应用层提供通用服务支持，如账户管理服务，session管理服务等，其又细分为逻辑处理层与数据接口层。而数据层负责提供数据存储访问服务，如数据库服务，缓存服务，文件服务，搜索服务等。

接入层采用了CDN，WAF，SLB等技术实现。由于系统核心是跨国一对一视频聊天，所以用户对网络延迟非常敏感。为此，我们采用CDN技术。CDN通过全局负载技术将用户的访问指向距离最近的边缘服务器，由边缘服务器响应用户请求。这使得用户就近获取所需内容，降低网络拥塞，提高用户响应速度。为了防止来自DDOS等恶意网络攻击，我们采用了WAF技术实现一系列针对HTTP/HTTPS的安全策略来保护我们的Web应用。为了应对日益提高的数据吞吐量，系统扩展性，系统可用性，我们采用了负载均衡技术。负载均衡技术的实现有多种手段，有通过硬件技术实现的F5，专业的负载均衡软件LVS，HAproxy等。经过讨论，之后出于对成本与技术成熟度等方面的考虑，我们决定采用Nginx实现负载均衡。通过对Nginx中upstream模块的配置，实现了在多台服务器的反向代理加载负载均衡。并且要让配置生效，我们不需要重启Nginx服务器，只需要reload配置即可。除此之外，还有API网关等问题，这里就不再赘述了。

应用层中，我们将系统根据应用进行水平划分，这有助于代码管理与维护。我们将系统分为课件管理系统，公众直播系统，学员测试系统，课程管理系统等十余个子系统，这里以课件管理系统为例。课件管理系统负责学员上课所用的课件，有课件编辑，课件预览，课件交互，课件展示等多个功能模块。功能模块调用服务层的服务支撑，如课件交互需要调用服务层由ActiveMQ实现的stomp通信服务，通过该通信服务，实现教师端与学生端的课件的同步，从而使得课件交互变得有趣，生动，具有互动性。另一方面为了区别教师端与学生端的交互权限，课件模块还需要调用服务层的账户服务，确定用户身份，从而明确用户在课件交互中的交互权限。与此同时，为提高课件的可修改性，可互动性等，课件采用H5编写。应用层主要采用structs这一基于J2EE平台的MVC框架，主要通过Servlet与JSP技术实现。另外还有动静分离，动态资源静态化等，这里不再赘述。

服务层采用了dubbo服务框架等技术实现。随着服务器规模的扩大，开发人员的增多，每个应用都变得复杂，臃肿，代码存在大量重复。为解决这个问题，提出了两个方案。一个是将应用拆分得更小，确保每个应用都保持在一个合适的大小。好处是设计能够较快地完成，代码也较容易实现。这个方案存在一些问题，一方面数据库的连接数压力依旧存在，另一方面，代码的冗余依旧存在。比如，在课件系统的交互应用与个人中心的计费应用都需调用账户相关的功能，这就造成了代码的冗余。所以我们采用了第二个方案-服务化方案。服务化方案，即应用层和数据层中增加一个服务层。首先从结构上来看，系统结构更为清晰明了，更为立体。稳定性上来看，许多散落的代码成为了通用服务，并交付专门的团队负责运维。一方面提高了代码质量，另一方面由于核心模块，修改和发布的次数将减少，这也会提高稳定性。最后，底层资源统一由服务层管理，结构更为清晰，也更有利于提高效率。出于对成本与技术成熟度，以及技术支持的考虑，我们采用了阿里研发的dubbo服务框架。在服务框架实际操作时有两个问题：服务框架自身的部署方式问题与实现服务框架所依赖的一些外部jar包与应用自身依赖的jar包之间的冲突。前者，我们通过Tomcat作为Web容器，而服务框架作为容器的一部分。后者，我们通过Java的ClassLoader将服务框架自身用的类与应用用的类进行隔离。为了提高服务层效率，我们采用了不同服务的线程池的隔离以及通布式环境中的请求合并。这有效降低了整个系统的负载，提高处理效率。除此之外，服务调用端的流控处理，异步服务调用，通过Future方式对远程服务调用的优化等问题，限于篇幅，不再赘述。

数据层涉及缓存，文件系统，数据库，数据通知服务，搜索系统等模块。由于用户对数据的访问具有集中性，所以我们基于SpringCache与Redis实现了缓存机制。由于系统的业务特性，数据库往往是读操作远多于写操作，所以我们对数据库进行了读写分离。数据访问方面，Java已经有很多成熟技术，大致分为三种。第一种是为用户提供专有API，这种方法便于实现功能，但是通用性较差。第二种是通过JDBC方式访问数据库，数据层本身作为一个JDBC的实现，也就是暴露出JDBC的接口给服务层。该方法成本很低，迁移成本也非常低，但开发成本相对高一些。第三种方式是基于ORM或类ORM接口的方式。我们采用的就是这种方式，使用数据库时使用ORM框架-Mybatis框架，再将框架包装一层，用于实现数据层功能，对外暴露的仍然是Mybatis的接口。该方法开发高效，敏捷，成本较低，而且兼容性不错。此外，我们采用solr作为数据层搜索引擎，数据访问层物理部署采用Proxy方式等。限于篇幅，不在赘述。

最终项目成功上线，正常运行了近一年半，并受到业界争相模仿。在系统的架构设计中，我们引入了层次架构的设计思想，有效地降低了维护成本，提高了系统的开放性，可扩展性，可重用性以及可移植性。当然还是存在一些问题的。如H5课件采用http协议，易被ISP等劫持，嵌入广告，可以将协议修改为https来解决。