1.快速审题
写作文要先审题，架构师论文命题也是如此。论文命题除了确定题目之外，还会给你写作要求。而这个写作要求会告诉你本命题涉及的知识点有哪些，并给你确立一个写作向。这个可以参考后面的论文真题分析。
2.确定题目
在填写并确认好个人信息之后，先看题，看完之后选择一个最有把握的。如果感觉都没太有把握，就选一个命题描述说明比较多的，这样你可以获得更多有用的信息，写的内容也更容易贴近主题。
3.构思正文内容
两个小时的写作时间，2500字，基本上是没有什么思考的空间的。当你确定题目之后，你的脑海里，就得列举出你的正文内容要写哪些东西了。
正文内容分为两部分。一部分是理论知识层面，即写作要求中让你阐述知识点概念的部分， 另一部分就是项目实践层面，即此理论或技术框架为什么要应用于项目，如何应用于项目、应用于项目之后获得了怎么样的结果。这一块可以参考后面部分。
4.学会分段
每一大段或者两小段对应一个知识点。每段开头先点题，先说明这一段要写的知识点是那个。然后将理论与技术框架或者实现方法对应起来，接着描写技术框架的选型依据、应用、优势及取得的效果。
如果分段太少，你就会发现写着写着突然没话了，只能乱写一通。如果分段太多，其一是知识点可能不够，其二是草草几笔带过一个知识点，让人觉得没有深度，也容易失去得分点。
5.学会思维发散
假如你要升级一个组件，需要写一个升级报告。当你无从下手的时候，你写一些性能提升、 运行稳定性提升、主备负载均衡高可用、故障用户无感知等等专业词语，让人看起来就是有一种高大上的感觉。然后再和老版本对比，详细描述一下新特性，大功告成。
在考场上，别花太多时间思考，时间不够，这个时候就要体现个人思维发散能力了。
但也不是为了凑点字数而乱写一通，肯定是要围绕主题有理有据。可不能加一些没用的状语或者语气词，让文章看起来很没有技术含量。
6.论文范文
范文一：论软件系统架构风格
系统架构风格（System Architecture Style）是描述某一特定应用领域中系统组织方式的惯用模式。架构风格定义了一个词汇表和一组约束，词汇表中包含一些构件和连接件类型，而这组约束指出系统是如何将这些构件和连接件组合起来的。软件系统架构风格反映了领域中众多软件系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。软件系统架构风格的共有部分可以使得不同系统共享同一个实现代码，系统能够按照常用的、规范化的方式来组织，便于不同设计者很容易地理解系统架构。
请以“软件系统架构风格”论题，依次从以下三个方面进行论述：
1．概要叙述你参与分析和开发的软件系统开发项目以及你所担任的主要工作。
2．分析软件系统开发中常用的软件系统架构风格有哪些？详细阐述每种风格的具体含义。
3．详细说明在你所参与的软件系统开发项目中，采用了哪种软件系统架构风格，具体实施效果如何。
范例
摘要部分：
本人于**年**月参与**项目，该系统为***，在该项目组中我担任系统架构师岗位，主要负责系统整体架构设计。本文以该车联网项目为例，主要讨论了软件架构风格在该项目中的具体应用。底层架构风格我们采用了虚拟机风格中的解释器，因该公交共有几十种不同的数据协议，使用解释器风格可以满足整车数据协议兼容性需求；中间层关于应用层的数据流转采用了独立构件风格中的隐式调用，以减低系统间耦合度、简化软件架构，提高可修改性方面的架构属性；应用系统层采用了B/S的架构风格，统一解决公交行业性难题“实施推广难、维护难”问题。最终项目成功上线，获得用户一致好评。
【注意：实际写作中相关项目情况应介绍清楚，摘要字数（包括标点符号）一般写到300到320字】
正文部分：
随着**，**集团自**年**月起****，规划***。【项目背景内容可分2段写，第1段简要说明下项目来龙去脉】
**年**月我司**委托建设***项目。本项目****，我在项目中担任系统架构师职务，主要负责系统整体架构设计，该系统主要***，主要功能模块包括**。【第2段对系统整体情况进行细致介绍，项目背景第1、2段内容可以写到400到450字】
在架构工作开始阶段，我们便意识到，架构风格是一组设计原则，是能够提供抽象框架模式，可以为我们的项目提供通用解决方案的，这种能够极大提高软件设计的重用的方法加快我们的建设进程，因此在我司总工程师的建议下，我们使用了虚拟机风格、独立构件风格以及B/S架构风格这三种较常用风格。虚拟机风格中的解释器架构风格能够提供灵活的解析引擎，这类风格非常适用于复杂流程的处理。独立构件风格包括进程通讯风格与隐式调用风格，我们为了简化架构复杂度采用了隐式调用风格，通过消息订阅和发布控制系统间信息交互，不仅能减低系统耦合度，而且还提高架构的可修改性。B/S架构风格是基于浏览器和服务器的软件架构，它主要使用http协议进行通信和交互，简化客户端的工作，最终减低了系统推广和维护的难度，以下正文将重点描述架构风格的实施过程和效果。
底层架构我们使用解释器风格来满足整车数据协议兼容性需求。解释器风格是虚拟机风格中的一种，具备良好的灵活性，在本项目中我们的架构设计需要兼容好86种不同can数据协议，一般来说这种软件编写难度非常高，代码维护难度压力也很大，因此这个解释器的设计任务便很明确了，软件设计需要高度抽象、协议的适配由配置文件来承担。具体的做法如下，我们对各个车厂的can数据结构进行了高度抽象，由于can数据由很多数据帧组成，每个数据帧容量固定并且标识和数据有明确规定，因此我们将can协议中的ID和数据进行关系建模，将整体协议标识作为一个根节点，以canid作为根节点下的叶子节点，使用XML的数据结构映射成了有整车协议链-数据帧-数据字节-数据位这4层的数据结构，核心的代码采用jdom.jar与java的反射机制动态生成java对象，搭建一套可以基于可变模板的解释器，协议模板的产生可以由公交公司提供的excel协议文档进行转换得到，解释器支持协议模板热部署，这种可以将透传二进制数据直接映射成java的可序列化对象，将数据协议的复杂度简化，后期数据协议更改不会对软件产生影响，仅仅更改协议模板文件即可，最终我们使用了86个协议描述文件便兼容了这些复杂的can数据协议，规避了can数据巨大差异带来的技术风险。
中间层我们使用独立构件风格中的隐式调用来简化构件间的交互复杂度，降低系统耦合度。主要的实现手段是，我们采用了一个开源的消息中间件作为连接构件，这个构件是apache基金会下的核心开源项目activemq，它是一款消息服务器，其性能和稳定性久经考验。由上文提到的解释器解析出对象化数据经过activemq分发到各个订阅此消息的应用系统，这些应用系统包括运营指挥调度、自动化机护、新能源电池安全监控等，这种多web应用的情况非常适合采用消息发布与消息订阅的机制，能够有效解决耦合问题，我们在编码的过程中发现只要采用这种风格的web应用，整个迭代过程效率极高，错误率降低，而且我们使用的spring框架，消息队列的管理完全基于配置，清晰简单，维护性良好，例如整车安全主题、运营调度主题、机护维修主题等消息队列分类清晰，可以随时修改其结构也能够随时增加其他主题的消息队列，不同的web系统监听的队列也可以随时变换组合，基于消息中间件的架构设计能够让系统的构件化思路得到良好实施，总体来说这种架构风格带来了非常清晰的数据流转架构，简化了编码难度，减低本项目的二次开发的难度。
应用系统层我们主要采用B/S的架构风格，主要用于解决公交推广难、维护难的问题。公交行业有一个明显的特点，公交子公司分布在全市各个地区，路途很远，且都是内网通讯，车联网络也是走的APN专网，一般是无法远程支持的，这给我们的系统推广以及后期维护带来了很大难题，我们可以想象如果使用C/S架构，更新客户端一旦遇到问题很可能需要全市各个站点跑一遍。这让我们在系统推广和维护方面面临较大压力。我们采用的B/S架构风格能够解决这个难题，并充分考量了现在相关技术的成熟度，例如现在的html5完全能够实现以前客户端的功能，项目中我们使用了大量的前端缓存技术与websocket技术，能够满足公交用户实时性交互等需求。这种风格中页面和逻辑处理存储在web服务器上，维护和软件升级只要更新服务器端即可，及时生效，用户体验较好，例如界面上需要优化，改一下Javascript脚本或者CSS文件就可以马上看到效果了。
项目于**年**月完成验收，这 1年内共经历了2次大批量新购公交车辆接入，这几次接入过程平稳顺利，其中协议解释器软件性能没有出现过问题，消息中间件的性能经过多次调优吞吐量也接近了硬盘IO极限，满足当前的消息交互总量，另外由于我们的项目多次在紧急状态下能够快速适应can协议变动，得到过业主的邮件表扬。除了业主机房几次突发性的网络故障外，项目至今还未有重大的生产事故，项目组现在留1个开发人员和1个售后在维护，系统的维护量是可控的，系统运行也比较稳定。
不足之处有两个方面，第一在架构设计的过程中我们忽略PC配置，个别PC因为需要兼容老的应用软件不允许系统升级，这些电脑系统老旧，其浏览器不支持html5，导致了系统推广障碍。第二在系统容灾方面还有待改善。针对第一种问题，我们通过技术研讨会说服业主新购PC，采用两台机器同时使用方式解决。针对第二种问题我方采用了服务器冗余和心跳监测等策略，在一台服务暂停的情况下，另外一台服务接管，以增加可用性。
