摘要
本文将主要讨论三种经典的软件架构风格，并且三种风格分别对应三个本人所负责的三个项目。首先是微内核风格是本人在开发自动售票机产品时使用。第二种管道过滤器风格是本人在开发架构地铁线网行车信号监察项目时的实践应用经历。最后再介绍一下微服务风格的架构项目，这是在2020年某某城市地铁智能运维项目中的应用。由于本人所在的单位是为铁路和地铁提供技术服务和解决方案的研究机构，故本人所阐述的项目背景也以轨道交通行业为主。软件架构风格发展到当今已经枝繁叶茂了，这极大的扩展了架构师选择架构风格的范围。本文首先宏观上罗列一下架构风格家族的成员和概念，中间详细讨论一下三种结合实践的软件架构风格。最后小结一下软件架构风格的意义。
正文
掌握软件架构风格的相关知识是每个架构师的必修课，即使不能各个风格都经历和擅长，但通过学习达到能识别或者辨析各种架构风格也是相当必要，为日后架构工作时选择准确的风格来匹配业务场景提供帮助。宏观上由于软件风格不断垂直细分，风格与风格是之间关系也略复杂了。下面梳理一下或相似或隶属的关系。在独立构件架构风格中，包括事件架构风格、进程通信风格。在虚拟机风格中包括解释解析器风格、规则系统风格。仓库风格中包括黑板风格、超文本风格、数据库风格。注意要区分这不是数据流风格，因为数据流风格强调的数据处理的过程流环节，它包括了批处理架构风格、管道过滤器风格，稍后会重点讲。还有调用返回风格也是比较常用的，包括了主程序子程序风格、层次结构风格、面向对象风格，其中层次结构风格，又不同于层次架构风格，在后者中分了B/S，C/S和三层c/s。当两层C/S中独立出了服务器后，业务逻辑就不在与表示层耦合了，这样客户端就变成了瘦客户端。这样风格的程序是比较容易移植和方便客户端部署，增加安全性。尤其是能在某些客户端资源有限或者紧张的场景中使用。其它，还有闭环风格，C2风格以及SOA家族的分布式风格。
软件架构风格，是描述了某一特定领域中系统的组织方式和惯用模式，它定义了一个系统家族，包括体系结构定义，一个词汇表和一组约束。词汇表，包括一些构件和连接件类型。而这组约束指出系统是如何将这些构件和连接件组合起来的。反映了领域中众多系统所共有的结构和语义特性。
以微内核风格为例，通常包括微内核、插件和UI界面。仅是从语义上就很容易理解微内核和插件的约束关系。即插件是插在微内核上，当插件脱离微内核构件，微内核可以支撑程序继续工作。就像是热插拔U盘时并不影响电脑的其它工作和其它硬件。在复杂的应用系统场景中，当插件不可用的时候，可能会出现降级服务，但应用不会崩溃。大家都体验过自动售票机，简称tvm。它包括了出售单程票，充值一卡通，找零。现在的一些更先进设备，还有二维码的扫描器，一般几个硬件配合围绕着一个应用服务。但当不能收硬币时可以收纸币，不能收纸币时可以扫二维码，不能售单凭单程票，tvm就降级，降级服务为充值一卡通，打印机坏了就提醒不要发票，询问用户是否可以接受。这些TVM的应用场景很多人都经历过，本人开发tvm机内软件，就需要把各种软硬件模块抽象成插件。而主控，也就是微内核的角色，他掌握着事件循环，就像大脑来管理协调各种器官一样。tvm的界面与主控的是分离的，通过socket协议通信，所以严格来说这是界面分离式的微内核架构。界面（UI）可以把插件的状态显示，当所有的硬件插件不服务，界面（UI）还是可以查询地铁的线路信息。想必这种风格已经给大家很形象的认识了。
接下来介绍数据流风格的子风格–管道过滤器风格。通常每个构件都有输入和输出，数据在各种环节中处理（批处理风格是顺序处理的）。管道过滤器风格的特点是，在输入未处理完时，组件输出就已经产生了，最后呈现结果给外部或输出给其它构件。而这个构件就是过滤器。在此项目中之所以没有选择相似的批处理风格来架构，是因为信号数据是实时的指令流，而非纯后台作业。并且处理步骤之间并没有清晰的分界。所以，为了不延迟信号的连贯渲染，就只能用管道过滤器风格。同时也未使用管道过滤器可以并发的特性。本人在架构线网行车信号监察项目时的业务场景如下：外部信号承包商有一套信号协议，包括20多条指令，其中包括道岔、信号灯，还有轨道状态，还有其他的一些信号设备状态。而同时本公司内部也存在着一套信号协议和成熟的渲染程序。如果改造渲染程序来适配外部的信号协议将是巨大的工作量，并且伴随风险。而为了快速上线和高可靠性的质量属性要求。本人选用了管道过滤器风格实现了架构。即新开发了协议转换组件，它相当于风格中的过滤器角色。软件工作时，原有的分发数据的通信模块会直接调用新开发的组件，完成过滤转换。软件很快就成功的接入了外部行车信号的数据。为了过滤器转换处理效率提升，本人使用了内存管理算法健全和控制内存api强大的c和c++开发。当然开发中对内存管理稍有不慎时也会碰到，内存随着进程时间运行越久，占用越大，在几分钟之内就可以让进程崩溃。
最后在重点讲一下特别火的新晋的软件架构风格-微服务风格。他属于SOA大风格中。在分布式风格中webservice/ESB是与微服务有着些许类似，但ESB是企业服务总线。一个介于服务提供者和消费者之间的环节，虽然解耦了两端的依赖，但同时也是中心化和集中化了。而微服务是面向轻量级的协议，比如HTTP，还有API无关性。服务可以用各种技术栈来建设，微服务提供者本身也可以是另外一个微服务的消费者。微服务解决了典型的RPC存在的调用者耦合问题。微服务的架构风格说明它是更纯粹的分布式。有着小独轻松的特点。每个微服务功能单一职责，细粒度且灵活。独立部署和交付。微服务也是独立运行在各自的进程空间中。本人在某某城市地铁智能运维项目中，组织研发了以微服务风格为主的架构产品。具体的场景是：地铁业主要求在平台上监察各专业设备的状态，比如车载电源、车载空调轨道的损耗。而各厂商的方案不能串行的调试开发适配，业主要求解耦单体程序且降低运维成本。因为任何的软件和服务难免升级，而且不可控，一旦有耦合关系存在，厂商就要牵着业主的鼻子走。此时应用微服务风格就是好的选择，它具有的特点也有了很大的用武之地。各厂商拆分细粒度的微服务组件，自己业务自治，快速部署和方便管理。交付在业主提供的paas上。解耦的附属好处就是复用，很多公用微服务可以被集中管理，比如很多专业都用到了身份认证和数据字典查询。当一步步的健全微服务的生态时，许多组件可以市场化的。优秀的算法会慢慢的涌现。并且以各种红利的方式来回馈开发者。新的风格引出新的架构模式，促进相关领域的深度融合。
小结并回头来看，梳理出来的架构风格思维导图就像一棵硕果累累的树。它是前人的经验总结。前辈栽树，后人来乘凉，使用成果。
项目一旦选定了软件的架构风格，大家就相当于有了一定的抽象上的共识。现在的软件架构风格俨然成为一种沟通的媒介了。当越来越多的人在使用这个“标准语言”时，作为从业者就更加需要在架构风格上努力来学习和积累经验。更重要的是熟练根据需求的场景来合理的、灵活的选择架构风格。用好一个架构风格是需要不断的实践的。在架构风格比较时要注意，有时即便系统组织风格相同，但约束上不同，就是细分的另外的一种架构风格。当项目的成败也并不代表架构风格的盖棺定论。我们需要不断的论证和优化，吸取其他架构风格的优点，屏蔽架构风格的缺点。因为项目是变化的，一种风格与另一种风格可以混合应用，也并不是互斥的。
总结就是一种创新，这是我们秉持的态度。希望更多的架构师能探索和实践并分享。大家一起互相学习，共同进步。
