参考书籍《架构真意-企业级应用架构设计方法论与实践》作者 范刚 孙玄 机械工业出版社本书通过架构设计方法论、分布式架构设计与实践和大数据架构设计三部分内容系统阐述了在软件开发的时候如何设计软件架构并且对1000万级、5000万级、亿级等不同量级流量的系统平台给出了不同的技术架构方案。书籍对于想快速熟悉软件架构构建思想和理念的从业者有较大的帮助。第一部分 架构设计方法论架构设计按照“5视图法”分为逻辑架构设计、数据架构设计、开发架构设计、运行架构设计、物理架构设计。第一章 架构师的修炼架构师的职责架构师是介于需求和研发中间的人既要技术好又要懂业务架构师是统领全局的将军架构师要作为“技术大牛”攻克技术难题架构师要作为战略规划师去规划未来。顶级架构师的三个特征1、顶级架构师在成长历程中依次跨越愚昧之巅、绝望之谷、开悟之坡与持续平衡的高原这四个关键阶段实现认知的逐步提升。在这一过程中他们脚踏实地扎实积累基础知识积极投身实践在丰富的项目历练中积累了宝贵的实操经验。2、他们始终保持勤于思考的习惯善于从复杂的现象中抽丝剥茧学会运用抽象思维精准抓取事物的本质特征。凭借长期的磨砺他们逐渐具备了举一反三的能力能够快速吸收新知识、掌握新技能。3、尤为突出的是即便涉足全新领域他们也能凭借深厚的知识积淀与敏锐的思维洞察力迅速获取比常人更为深刻的认知与领悟。此时他们已深谙架构设计的哲学本质能够站在更高的层次、更宏观的视角去思考问题为项目的架构规划与决策提供极具前瞻性与战略性的指导 。第二章节 逻辑架构设计逻辑架构就是基于客户的需求设计好软件要为客户提供哪些功能。需求分析方法用例模型。用例模型是一套基于UML用例图进行需求分析的实践方法。用例模型包括三个元素用例use case、参与者actor、系统边界boundary。用例描述的是系统为用户提供哪些功能也就是系统能为用户做什么通常绘制成一个椭圆。参与者就是使用本系统的人他们按照职责而被划分成不同的角色。用例编写中最重要的就是编写事件流包括基流、分支流和替代流。基流又叫成功流或者主流程指的是在所有流程都操作成功的时候整个流程是怎么走下来的。分支流和替代流的区别是如果走了分支流一定还会回到主流程替代流又叫异常流如果走了替代流就会结束流程不再回到主流程。业务需求列表又称为需求跟踪表是用户对业务需求的最原始描述。需求规格说明书 在用户编写的原始需求的基础上经过业务和需求两方面确认后的业务需求。原型法全名快速原型法是指当捕获了一批业务需求后立即使用可视化工具快速开发出一个原型交给用户去试用、去补充、去修改。典型工具有Axure、墨刀、VUE等。软件退化在软件上线后往往会经历各种各样的需求变更需求变更一次软件就修改一次软件修改一次质量就下降一档不论第一次的设计质量有多高经过几次变更后软件都会进入一种低质量、难以维护的状态这就叫软件退化。软件退化的根源 软件的本质就是对真实世界的模拟每个软件都能在真实世界中找到它的影子。因此软件中业务逻辑正确与否的唯一标准就是是否与真实世界一致。软件做成什么样子即不由我们决定也不由客户决定而是由客观世界决定。客户总在改需求是因为他们也不确定客观世界的规则只有遇到问题了才能想的起来。因此对于我们来说与其唯唯诺诺的按照客户的要求去做软件不如主动的在理解业务的基础上去分析软件而后者更有利于我们降低变更的成本。那么真实世界是怎么样我们就怎样开发软件不是就简单了吗其实并非如此因为真实世界非常复杂而深刻理解真实世界中的这些业务逻辑是需要一定的时间的。因此我们最开始只能认识真实世界中哪些简单清晰易于理解的业务逻辑把他们做到我们的软件里。所以每个软件的第一个版本总是那么清晰明了易于设计。然而当我们把第一个版本的软件交付用户使用的时候用户会发现还有很多不简单、不明了、不易于理解的业务逻辑还有些需求没有做到软件里。这使得用户在使用软件的过程中不方便、和真实世界不一致。因此客户就会提Bug提新需求。在我们不断地修复Bug实现新需求的过程中软件的业务逻辑会越来越接近真实世界使得我们的软件越来越专业让用户感觉越来越好用。但是在软件越来越接近真实世界的过程中业务逻辑也会变的越来越复杂软件规模越来越庞大。为了避免或者减少软件退化需求变更和设计需要遵守“开放封闭原则OCP”和“两顶帽子”的设计方式开放封闭原则OCP1、开放原则我们开发的软件系统对于功能扩展是开放的Open for Extension即当系统需求发生变更时我们可以对软件功能进行扩充使其满足客户的新需求。2、封闭原则对软件代码的修改应该是封闭的Close for Modification即在修改软件的同时不要影响到系统原有的功能新代码和老代码应该隔离不能在同一个类、同一个方法中。两顶帽子设计方式1、在不增加新功能的情况下重构代码调整原有程序结构以适应新功能2、实现新的功能。DDD-Domain Driven Design 领域驱动设计将真实世界和软件世界对应起来的设计思想包括三个方面的内容1、真实世界有什么事物软件世界就有什么对象2、真实世界中这些事物都有哪些行为软件世界中这些对象就有哪些方法3、真实世界中这些事物间都有哪些关系软件世界这些对象间就有什么关联。领域驱动设计DDD的设计遵守“单一职责原则”软件系统中的每个元素只完成自己职责范围内的事而将其他的事交给别人去做自己只是去调用。第三章节 数据架构设计数据架构就是对功能性需求进行分析抓住功能性需求的核心。传统的软件设计过程需求文档----数据库设计----程序设计面向对象的软件设计过程需求文档----用例设计----领域模型设计----数据库设计程序设计要将领域模型映射到程序设计最终都会落实到三种类型的对象设计服务、实体和值对象。服务领域对象之外的操作和行为。服务通常承担两种职责接受用户的请求、执行某些操作。实体通过唯一一个标识字段来区分真实世界中的每一个个体的领域对象。比如学员对象就是一个实体。可变性是实体的特点。值对象 Value Object真实世界中些那一成不变的、本质性的事物。比如地理位置、行业、职位。不变性是值对象的特点。聚合DDD中的一个重要概念真实世界中那些整体和部分的关系如订单和订单明细当整体不存在时部分就没有了意义。聚合的好处当聚合内部的业务逻辑发生变更时候只和聚合内部有关只需要对聚合内部进行更新而与外部程序无关从而有效降低变更的维护成本提高系统的设计质量。聚合根在聚合关系中对部分的操作必须要通过整体整体成为了外部访问的唯一接口整体被称为聚合根。仓库Repository采用DDD后通常会实现一个仓库Repository去完成对数据库的访问。工厂 DDD中通过装配来创建领域对象是领域对象生命周期的起点如订单工厂会将装配好的订单对象返回给订单仓库。问题域真实世界的问题和业务叫做问题域。限界上下文Context Bound对一个复杂系统的领域驱动设计就是以子域为中心进行领域建模比如在线订餐系统包含了用户下单、饭店接单、骑士派送等子域。这样绘制出的一张一张的领域模型称为限界上下文。第四章节 开发架构设计开发架构就是系统性的规划软件代码的层次骨骼。开发设计阶段架构师主要完成以下几项工作系统规划、接口定义、系统分层、技术选型、代码规范。MVC设计模式MVCModel-View-Controller设计模式是一种广泛应用于软件开发的架构模式它将软件应用程序分为三个主要部分模型Model、视图View和控制器Controller通过明确的职责划分提高了代码的可维护性、可扩展性和可测试性。MVC模式被J2EE架构所广泛采用如今MVC主要负责完成系统前后端交互即完成前端提交的请求参数并将其塞入值对象中或者将执行结果返回给前端。在这个过程中不包含任何业务逻辑与判断仅仅进行一些数据转换。整洁架构The Clean Architecture以圆环的形式把架构分成了几个不同的层次因此又被称为洋葱架构The Onion Architecture中心是业务实体Entity与业务应用Application业务实体就是那些核心业务逻辑而业务应用就是面向用户的服务Service他们合起来构成了业务领域层也就是通过i领域模型形成的业务代码的实现。整洁架构的最外层是各种技术架构包括与用户界面的交互、客户端与服务器的网络交互、与硬件设备和数据库的交互以及与其他外部系统的交互。而整洁架构的精华在于其中间的适配器层他通过适配器将核心的业务代码与外围的技术架构进行解耦。因此如何设计这个适配层让业务代码与技术框架解耦让业务开发团队和技术开发团队各自独立的工作就成了整个整洁架构落地的核心。在整洁架构设计中适配器层通过数据接入层、数据访问层与接口层等几个部分的设计实现与业务的解耦。命令与查询职责分离Command Query Responsibility SegregationCQRS是软件大师Martin Follow在《企业应用架构模式》提出来的一种架构设计模式该模式将系统按照职责划分为命令即增删改操作和查询两部分。所有命令部分的增删改操作都应该采用DDD的思想进行软件设计从而更好的应对大规模复杂应用所有的查询功能则不适用于DDD而应该采用事物脚本Transaction Script模式即直接通过SQL语句进行查询。第五章节 运行架构设计运行架构就是软件在运行过程中所体现出来的非功能性需求。软件重构的几个简单易行的方法抽取方法、抽取类、抽取接口。第六章节 物理架构设计物理架构就是软件的物理部署及网络拓扑。网络架构图网络架构图将系统建设分为四个区域分别是互联网区域、数据隔离区区域、外网区域和内网区域。数据隔离区域主要负责入侵检测、漏洞扫描和负载均衡。外网区域负责CA网关检查、身份认证、安全审计和病毒防护。内网系统主要是各业务系统的处理端。同时内部的员工也是通过企业内网访问内部的管理系统完成对用户业务的受理、审批、核准等操作。系统架构(SA)或者应用架构AA:架构师站在全局的角度给用户绘制一张总体架构图包括逻辑架构、数据架构、开发架构、运行架构和物理架构。第二部分 分布式架构设计与实践第七章 分布式架构设计1、1000万以内的流量的软件架构设计客户端CDN节点Nginx反向代理本地缓存应用集群数据库2、1000万以上的流量的软件架构设计客户端CDN节点Nginx反向代理本地缓存应用集群数据库集群RAC配合微服务进行数据库的纵向切分加如hash求余的横向切分)3、5000万以上的流量的软件架构设计客户端应用服务其内存数据库数据库4、10000万以上的流量的软件架构设计服务网关业务层服务层数据层其中服务网关要考虑负载均衡、身份鉴权、限流措施和安全防护业务层需要考虑动静分离、异步化设计和熔断机制服务层需要考虑横向扩容、故障转移、服务降级、数据缓存数据层需要考虑读写分离、数据拆库、分布式数据库、大数据转型技术。GemFire一种比Redis更强大的分布式内存数据库被12306网站所采用提供了一整套的数据持久化方案可以将GemFire数据库中的数据同步到传统的关系型数据库、Hadoop大数据平台等存储设备唯一的缺点是其为商用软件而非开源开源框架且价格不菲。第八章 微服务架构设计什么是微服务架构1、是一种架构风格和设计模式2、提倡将大的应用分割成一系列的小的服务3、每个服务专注于各自单一的业务功能4、每个服务运行于独立的进程中有清晰的服务边界5、采用轻量级的通信机制HTTP/REST来实现互通、协作。一个典型的在线商城的微服务架构的数据库设计为对于商品微服务和客户微服务这两类的微服务典型的特征是数据量小且需要反复读取因此采用一个小型的Mysql数据库平且在前面设计一个Redis缓存对于交易微服务其特点是高并发和大数据写入一个数据库肯定不能满足他的数据要求因此采用分布式的NewSQL数据库(如TiDB)这样既可以使用分布式来分散用户的压力又可以利用NewSQL数据库保障数据的一致性。对于经营分析和业务查询微服务其特定是对海量数据的数据分析和秒级查询首先要通过读写分离将数据从生产库抽到NoSQL数据库或者大数据平台组成的查询库中然后通过OLAP建模如Kylin或者建立分布式索引如ElasticSearch就能很好的满足这类微服务的数据需求。第九章 基于云端的分布式部署DevOPS运维平台架构各个开发团队彼此独立地开发各自的微服务并上传到各自的Git服务器接着持续集成工具Jenkins每天自动从各Git服务器中下载代码将其打包并制作成Docker镜像发布到镜像仓库中。然后在Kubernetes中定义每个微服务的节点个数并将其自动化部署到云端服务平台中。Docker和Kubernetes的关系二者是共生关系不是k8s要替代dockerK8s是构建与Docker之上的分布式管理工具让Docker能够更好地完成分布式部署促进docker的发展因此他们是互相促进的关系。