如何学好软件系统架构？什么是软件架构

本文目录

• 如何学好软件系统架构
• 什么是软件架构
• 什么是软件架构模式
• 1、软件架构有什么我们目前的软件开发架构是基于什么的2、资源分类有哪些
• 软件架构中的分层都有哪些类型
• 软件架构模式基本概念及三者区别
• 系统软件架构中，现在很流行微服务，那么使用微服务就一定好么微服务有哪些缺点呢

如何学好软件系统架构

学好软件架构，主要在于多做大型复杂需求，在做需求中体会别人设计的架构的优缺点，最后尝试优化这个架构，这是学好架构的不二法门。

架构不是看书听课学得会的。面对同一行字同一句话，有实践和没实践的人，完全是不同的理解，没实践的人甚至连问题都问不出来。

软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系，而且指定了整个软件系统的组织和拓扑结构，提供了一些设计决策的基本原理。

什么是软件架构

软件架构 软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。 软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口_(计算机科学)来实现。 软件体系结构是构建计算机软件实践的基础。与建筑师设定建筑项目的设计原则和目标，作为绘图员画图的基础一样，一个软件架构师或者系统架构师陈述软件构架以作为满足不同客户需求的实际系统设计方案的基础。 软件构架是一个容易理解的概念，多数工程师（尤其是经验不多的工程师）会从直觉上来认识它，但要给出精确的定义很困难。特别是，很难明确地区分设计和构架：构架属于设计的一方面，它集中于某些具体的特征。 在“软件构架简介”中，David GArlan 和 Mary Shaw 认为软件构架是有关如下问题的设计层次：“在计算的算法和数据结构之外，设计并确定系统整体结构成为了新的问题。结构问题包括总体组织结构和全局控制结构；通信、同步和数据访问的协议；设计元素的功能分配；物理分布；设计元素的组成；定标与性能；备选设计的选择。” 但构架不仅是结构；IEEE Working Group on Architecture 把其定义为“系统在其环境中的最高层概念”。构架还包括“符合”系统完整性、经济约束条件、审美需求和样式。它并不仅注重对内部的考虑，而且还在系统的用户环境和开发环境中对系统进行整体考虑，即同时注重对外部的考虑。 在 Rational Unified ProcESs 中，软件系统的构架（在某一给定点）是指系统重要构件的组织或结构，这些重要构件通过接口与不断减小的构件与接口所组成的构件进行交互。 从和目的、主题、材料和结构的联系上来说，软件架构可以和建筑物的架构相比拟。一个软件架构师需要有广泛的软件理论知识和相应的经验来事实和管理软件产品的高级设计。软件架构师定义和设计软件的模块化，模块之间的交互，用户界面风格，对外接口方法，创新的设计特性，以及高层事物的对象操作、逻辑和流程。 是一般而言，软件系统的架构（ArchitECture）有两个要素： ·它是一个软件系统从整体到部分的最高层次的划分。 一个系统通常是由元件组成的，而这些元件如何形成、相互之间如何发生作用，则是关于这个系统本身结构的重要信息。 详细地说，就是要包括架构元件（Architecture Component）、联结器（Connector）、任务流（TASk-flow）。所谓架构元素，也就是组成系统的核心"砖瓦"，而联结器则描述这些元件之间通讯的路径、通讯的机制、通讯的预期结果，任务流则描述系统如何使用这些元件和联结器完成某一项需求。 ·建造一个系统所作出的最高层次的、以后难以更改的，商业的和技术的决定。 在建造一个系统之前会有很多的重要决定需要事先作出，而一旦系统开始进行详细设计甚至建造，这些决定就很难更改甚至无法更改。显然，这样的决定必定是有关系统设计成败的最重要决定，必须经过非常慎重的研究和考察。

什么是软件架构模式

软件架构模式有以下几点：(1)管道/过滤器模式:其典型应用包括批处理系统。(2)面向对象模式:其典型应用是基于组件的软件开发CBD。(3)事件驱动模式:其典型应用包括各种图形界面应用。(4)分层模式:其典型应用是分层通信协议，如ISO/OSI的七层网络模型。(5)客户/服务器模式(Client/Server，C/S):为了解决C/S模式中客户端的问题，发展形成了浏览器/服务器(B/S)模式:为了解决C/S模式中服务器端的问题，发展形成了三层(多层)C/S模式，即多层应用架构。软件架构模式有以下几点：(1)管道/过滤器模式:其典型应用包括批处理系统。(2)面向对象模式:其典型应用是基于组件的软件开发CBD。(3)事件驱动模式:其典型应用包括各种图形界面应用。(4)分层模式:其典型应用是分层通信协议，如ISO/OSI的七层网络模型。(5)客户/服务器模式(Client/Server，C/S):为了解决C/S模式中客户端的问题，发展形成了浏览器/服务器(B/S)模式:为了解决C/S模式中服务器端的问题，发展形成了三层(多层)C/S模式，即多层应用架构。

1、软件架构有什么我们目前的软件开发架构是基于什么的2、资源分类有哪些

软件架构是指在一定的设计原则基础上，从不同角度对组成系统的各部分进行搭配和安排，形成系统的多个结构而组成架构，它包括该系统的各个组件，组件的外部可见属性及组件之间的相互关系。组件的外部可见属性是指其他组件对该组件所做的假设。软件架构设计就是从宏观上说明一套软件系统的组成与特性。软件架构设计是一系列有层次的决策，比如：功能与展现的决策；技术架构的决策；自主研发还是合作；商业软件还是开源软件。业务需求层出不穷；软件系统越来越复杂；参与的人越来越多；共性和特殊性的问题越来越多；技术发展日异月新。分类描述1解决方案架构师与客户探讨业务需求，将业务、市场，与技术、产品结合起来，为客户提供解决他们需求的方案。2系统架构师也称应用架构师。最终确认和评估系统需求，并将业务转换为技术，为研发人员制订核心框架与技术规范为研发工作澄清技术细节并扫清技术障碍。3平台架构师这里的平台其实包括两个平台，一个是系统平台，也就是负责搭建多个系统整合的系统应用平台；另外一个其实是基础平台，是专门负责搭建基础技术平台；两者其实区别蛮大，也经常容易被从业人员混乱。举个简单例子，金蝶有平台架构师一职，但是金蝶BOSS应用和金蝶中间件两者招聘的对象和技术要求是截然不同的。4业务架构师业务架构其实已经开始脱离技术层面了，但是它要求架构师有跨越多系统的大局观，去整合和组织不同系统的技术平台与交互模式。其实这个职位的未来也就是CIO了。5网络架构师过去，我们可能听的最多的是网络工程师。不错，一个优秀的网络架构师必须有足够的网络技术基底，并且它的关注点也是系统的基础架构。比如说如果搭建并优化集群环境，如果构建基于云计算的系统应用与部署等等。它对于像淘宝、腾讯这样的互联网公司是极其重要的。6移动架构师移动互联网的迅猛发展横向和纵向都细分出了很多新的职责和岗位，移动架构师的职责和作用日益重要，既要整体和全局考虑整个前后端的软件系统架构，又要重点深入移动客户端的架构设计的方方面面，既要有跨平台思维，又要拿捏好原生和混合开发的尺度，另外移动应用的特点，导致移动架构师必须要比传统系统架构师更加注重非功能性的质量属性。7前端架构师这也是移动互联网的迅猛发展而细分出来的新的职责和岗位，这里的前端特指网站开发中的前端，主要考虑前端呈现层的设计（HTML/CSS/JS/AJAX/RIA/?），跨浏览器设计等等。

软件架构中的分层都有哪些类型

关于系统架构和软件分层的概念我们在前几期的文章中曾经介绍过多次了。今天，云南java课程

经典的三层架构：

1.基础层：dao,帮助类，IO读写，资源加载等一些基础设施，他们作为整个系统基础的模块可以组合成业务层和服务层

2.业务层和服务层：典型的就是service,这里承载更多的是业务的实现，资源的组合调度，事务实现，等等，这里是整个系统核心的地方，下面整合底层dao以及事务，根据业务和场景灵活的把业务逻辑使用底层的基础单元拼接组合起来，上面为表现层提供具体的业务处理逻辑

3.表现层：接受外部的请求，并把调用对应的service操作具体业务，把终结果反馈给调用者或是用户

四层架构，在基础层基础之上还可以在分出一层：领域层，基础层还是提供基本的数据操作和IO与网络操作，不过领域层对基础层再来一次封装和整合，目的也是方便整合底层资源方便service层调用，简化业务层和基础层的复杂依赖

静态业务对象：

ViewObject:VO界面展示用到的数据对象

DomainObject:DO领域层对象，一般可以简约的理解为javabean对象，从业务中抽取的基本模型类

BussinessObject:BO业务对象一般也在service业务层，如果DO不能完全表达，可以使用BO获取更多信息的表达，并且还可以封装重用DO中的实体信息

PersistantObject:PO持久存储对象，一般作用于dao层，和数据库实体对应

DataTransferObject:DTO数据传递对象，用于封装参数，数据中转会，重构过程方法列表会用到

动态处理对象：

Controller控制器,Manager管理类,Service服务类,Repository,DAO数据源,Client客户端,Dispather转发器,Handler处理器,Interceptor拦截器

Helper,Utils帮助类

动态的配置文件与属性：

一些经常用到的开关和阈值一定要写在配置文件中，或有配置中心可以下发，不要在程序中写死，而且要有对相应的刷新机制api接口，调用后强制刷新配置参数

常用的比如：

活动的开始结束日期

业务中的大值，限制值等阈值

外界的URI:文件上传地址，静态资源位置，等等

.....等等一切可以借鉴Ioc理念抽取出来的配置变量

软件架构模式基本概念及三者区别

在做软件架构设计时,根据不同的抽象层次可分为三种不同层次的模式：架构模式(Architectural Pattern)、设计模式(Design Pattern)、代码模式(Coding Pattern)。 架构模式是一个系统的高层次策略，涉及到大尺度的组件以及整体性质和力学。架构模式的好坏可以影响到总体布局和框架性结构。 设计模式是中等尺度的结构策略。这些中等尺度的结构实现了一些大尺度组件的行为和它们之间的关系。模式的好坏不会影响到系统的总体布局和总体框架。设计模式定义出子系统或组件的微观结构。 代码模式（或成例）是特定的范例和与特定语言有关的编程技巧。代码模式的好坏会影响到一个中等尺度组件的内部、外部的结构或行为的底层细节，但不会影响到一个部件或子系统的中等尺度的结构，更不会影响到系统的总体布局和大尺度框架。架构模式(Architectural Pattern)一个架构模式描述软件系统里的基本的结构组织或纲要。架构模式提供一些事先定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。称之为系统模式。•MVC模式,一个架构模式常常可以分解成很多个设计模式的联合使用。MVC模式常常包括调停者（Mediator）模式、策略（Strategy）模式、合成（Composite）模式、观察者（Observer）模式等。•Layers（分层）模式，有时也称Tiers模式•Blackboard（黑板）模式•Broker（中介）模式•Distributed Process（分散过程）模式•Microkernel（微核）模式架构模式常常划分成如下的几种：一、 模块结构(From Mud to Structure)型。帮助架构师将系统合理划分，避免形成一个对象的海洋。包括Layers（分层）模式、Blackboard（黑板）模式、Pipes/Filters（管道/过滤器）模式等。二、分散系统（Distributed Systems）型。为分散式系统提供完整的架构设计，包括像Broker（中介）模式等。三、人机互动（Interactive Systems）型，支持包含有人机互动介面的系统的架构设计，例子包括MVC（Model-View-Controller）模式、PAC（Presentation-Abstraction-Control）模式等。四、Adaptable Systems型，支持应用系统适应技术的变化、软件功能需求的变化。如Reflection（反射）模式、Microkernel（微核）模式等。设计模式(Design Pattern)一个设计模式提供一种提炼子系统或软件系统中的组件的，或者它们之间的关系的纲要设计。设计模式描述普遍存在的在相互通讯的组件中重复出现的结构，这种结构解决在一定的背景中的具有一般性的设计问题。设计模式常常划分成不同的种类，常见的种类有：创建型设计模式，如工厂方法（Factory Method）模式、抽象工厂（Abstract Factory）模式、原型（Prototype）模式、单例（Singleton）模式，建造（Builder）模式等结构型设计模式，如合成（Composite）模式、装饰（Decorator）模式、代理（Proxy）模式、享元（Flyweight）模式、门面（Facade）模式、桥梁（Bridge）模式等行为型模式，如模版方法（Template Method）模式、观察者（Observer）模式、迭代子（Iterator）模式、责任链（Chain of Responsibility）模式、备忘录（Memento）模式、命令（Command）模式、状态（State）模式、访问者（Visitor）模式等等。以上是三种经典类型，实际上还有很多其他的类型，比如Fundamental型、Partition型，Relation型等等。设计模式在特定的编程语言中实现的时候，常常会用到代码模式。比如单例（Singleton）模式的实现常常涉及到双检锁（Double-Check Locking）模式等。代码模式(Coding Pattern)代码模式（或成例）是较低层次的模式，并与编程语言密切相关。代码模式描述怎样利用一个特定的编程语言的特点来实现一个组件的某些特定的方面或关系。较为著名的代码模式的例子包括双检锁（Double-Check Locking）模式等

系统软件架构中，现在很流行微服务，那么使用微服务就一定好么微服务有哪些缺点呢

下面简单回答下这个问题。在回答这个问题前还是先回顾下微服务架构。

微服务架构概述

微服务架构本质是单个业务系统彻底的组件化（前端，逻辑层，数据库）解耦，同时相互之间通过轻量的服务接口和协议进行协同。这和很早就谈到的组件化架构思想是一致的，实现微服务架构后，你会看到没有传统业务系统的概念了，有的只是微服务模块或小应用。微服务架构最近又炒的相当活，很多人会说SOA过时了，ESB过时了，甚至还有人用微服务架构去彻底的否定SOA和ESB，这些都是相当危险的信号。在我12，13年写企业私有云PaaS平台的一系列文章的时候，已经提出了业务能力组件化，组件服务化的微服务架构思想，但是实际应用实施效果并不太理想。

我们可以先看下从单体应用到微服务架构的变化图。

把这个核心搞清楚后，再来看下网上找到的对微服务架构的一些定义和阐述：

微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。

在了解了微服务架构后，我们来分析下微服务架构又哪些缺点和难点。

微服务模块拆分后，各微服务间集成复杂度指数级增加

简单举例来说，一个企业已经实施了5个业务系统，业务系统之间有10个接口。如果全部微服务化则可能设计到50个微服务模块，上100个接口和集成点。可想而知，在彻底实施微服务后，我们前期架构设计，后期集成和管控的复杂度增加10倍以上。这种集成难度会远超大多数人想象，如果拿真实做的项目来说，如果谈业务系统只有3个，而到微服务模块级别则有接近60个，而实际涉及到的集成接口上1000个。我们做任何一个复杂端到端业务的联调基本就需要花2，3周甚至更长的时间。互联网企业为何适合做微服务架构，其重要的一个原因就是互联网企业如电商平台，在进行了微服务化后各个模块之间耦合性很低，并不会有太多的集成和协同点。或者简单来说，各个微服务模块更多的是向上面的PC端或APP端提供服务能力，而模块横向间接口协同很少。正是在这种低耦合情况下，协同和集成相对来说容易。而转回到企业内部你会发现，在微服务模块化后，各个模块之间的集成点相当多，特别是业务系统拆分到模块或组件这一个级别后，很多原有内部的集成和依赖点全部暴露出来了，你都需要去很好的管理。由于这里面有大量的横向集成和协同点，因此导致的就是微服务模块间的横向集成异常复杂，远超很多互联网应用，这是实际你会面临的问题。

微服务模块拆分后，各微服务间集成复杂度指数级增加

只谈微服务架构的松耦合和高扩展性，而不谈开发和集成复杂度的都是耍流氓。实际上当前很多企业对微服务架构并没有如此迫切，互联网很多企业推行微服务架构更多的还是考虑到巨大的业务并发量下的系统弹性扩展能力，而实际大多数企业内应用往往并没有如此海量并发。其次，即使在并发量增加的情况下通过进行代码本身的优化，数据库调优或者升级硬件服务器资源都可以较好的解决性能问题。而做这些事情投入的成本远远小于微服务架构带来的开发复杂度增加成本，后期的运维管控成本。要做到完全微服务模块独立，微服务架构下最大的一个变化就是数据库也拆分开了，原来的一个业务系统如果分为5个微服务模块，那理论上就是5个独立的后台数据库，而且数据库间还不能随便相互连接和访问。只有这样微服务模块才能做到独立部署和管理。由于数据库拆分带来两个问题，其一是我们原来很简单的一个跨表查询操作现在无法做了，我们必须调用两个微服务模块提供的服务，查询到数据后再到逻辑层进行组合。其次最大的问题就是如果一个业务操作需要同时更新两个微服务模块的数据，由于服务本身无状态，导致了这种分布式事务问题很难解决。企业内业务系统很大一个特点就是业务逻辑和规则相对互联网更加复杂，而且有更高的事务一致性要求。正是由于这个原因，无法解决好分布式事务的问题都将直接导致后续数据不一致和业务错误。原来通过调用项目内一个API方法就能解决的问题，现在要调用远程WS接口才能解决，这本身就增加了开发和调试的复杂度。一个微服务模块与外部其它模块的集成和协同越少，你会发现该微服务模块和传统业务系统开发没太大区别，但是当其涉及到完成任何一个功能都需要调用外部微服务模块的服务接口时候，其开发模式和效率上就会带来巨大的变化。

微服务架构下运维难度增加

在实施了微服务架构后，运维的复杂度也是成倍增加，任何一个微服务模块出问题都可能影响到整个业务应用的功能使用。我们在运维时候不仅仅要健康单个微服务模块，还需要健康所有的接口服务监控状态。如果跟Docker集成了，我们看到整个性能监控和问题分析都会变麻烦了，没有实施微服务架构前发现问题，我们直接可以看应用服务器上类似tomcat或jboss日志，而实施了微服务架构后，应用容器已经是自动部署和动态分配的，原有的故障诊断模式行不通，而需要PaaS平台本身提供完整的预警和日志分析能力。再次，如果发现了性能问题或故障，我们的解决方案是如何的？我们如何保证不影响到业务运行，不出现数据的丢失，或者在微服务模块扩展的时候不出现业务中断等。这些已经不是简单的部署架构层面的冗余能解决的问题，而涉及到我们在整个微服务架构中的消息策略，事务管理机制，持久化机制等问题。

引入微服务后的实施难度增加

一个企业所涉及到的IT开发和架构能力以及企业本身的IT治理管控成熟度都将直接影响到微服务架构能否实施成功，要知道引入微服务架构后集成和后续运维等的复杂度都会成指数级增长。

方式1：引入的外部开发商进行微服务架构化如果一个企业本身IT部门规模小，软件以外购为主，那么势必在对ERP等各类软件的选型评估后引入不同的软件产品提供商或软件开发商。那么软件商本身都有了成熟的产品或架构，其产品内部的模块是否符合组件化和微服务架构的要求，我们不得而知。即使招标要求写明软件提供商提供产品需要基于SOA或微服务参考架构，但是实际上由于企业本身的IT能力和水平往往也无法验证，而对于软件厂商来说一定希望是卖现有产品，减少改造和定制实现利润的最大化。对于软件开发厂商来说对已有的软件产品是没有微服务架构改造的动力的。那在这种情况下要推动微服务架构实施落地必须的就是企业本身有很强的架构管控能力和甲方话语权。在曾经实施的案例里面可以看到，甲方在有较强的IT规划和架构设计能力情况下，才可能一开始就划分好微服务模块并且设计好微服务模块间的接口，在进行招标和选型。同时甲方话语权强的情况下，可以完全要求软件供应商按照自己定义好的标准，规范，架构进行微服务模块的开发。简单点来说顶层架构分解和接口设计能力不在单个微服务模块开发商手里面，而是在甲方手里，或者在甲方请的专门负责规划架构设计的技术咨询团队手里。在这种模式下，技术咨询团队应该对整体模块划分和后续集成负责，技术咨询团队就需要有业务和技术两方面的能力，同时有类似领域的规划设计经验，系统开发建设经验等。这些本身就对技术咨询团队提出了相当高的要求，可以来讲很少有技术咨询团队达到这个水平，包括埃森哲或德勤等也难。在微服务架构下，我们希望的是一个业务系统如果由三个微服务模块组成，在我们进行了前期的架构和接口设计后，我们完全可以将三个模块发标给不同的软件开发商建设和实施，然后在根据预先定义的服务接口进行集成。这个从理论上是行得通的，但是实际上出现两个问题。其一是刚开始的模块划分或接口设计不合理，在后面开发过程中才发现又很难再大变更。其二是微服务模块间的接口服务太多，导致了模块间的集成和联调异常复杂。从上面也看到引入微服务架构后，企业本身可以削弱单个软件供应商对企业本身的约束，防止被单一厂商绑定。因此企业没有特色要求，从软件厂商来说没有任何动力和意愿推微服务架构。方式2：企业自由开发团队实践微服务架构如果企业本身的IT成熟度没有达到一定阶段，显然是不可能推行实施微服务架构的。这个道理前面已经谈到过，在企业IT建设中，如果连粗粒度的业务系统以及它们之间的集成都管理不好，那么更没有能力管理细粒度的微服务模块。那么如果企业IT成熟度达到一定水平，在推广微服务架构还存在的难点如下：首先是架构设计能力的显性化，即架构设计这个工作的输入，输出和过程需要更加的显性化出来形成团队都认同的标准工件。一个业务系统没有拆分开时候，虽然有架构设计和组件划分，但是这个工作是属于团队内部的事情，即使架构设计不合理，在后期集成也可以通过诸多变通方式解决掉。而现在是不同的微服务模块可能分派到两个独立的团队开发，原来属于自己内部黑盒的问题变为团队间问题。简单来说你原来藏着或没做规范的东西太多，而现在这些不能再藏着掖着了，当真要把这些东西拿出来的时候，你才会发现你原来架构能力是有欠缺的。正如我们理解了一个东西，那么要让我们清楚的讲出来困难，那么我们的理解有欠缺。对于我们能讲清楚的东西，要系统的写下来有困难，那么说明我们讲的结构和条理有欠缺。其次管控要求和规范体系的建立，对于管控要求可以看到如果两个微服务模块分给同一个团队开发，如何才能保证开发的团队保持两个模块的完全独立和解耦，两个模块间不会出现相互交叉的数据库直接调用，也不会存在直接绕开Service接口的其它耦合调用？这些如果没有完整的管控和检查体系我们很难约束。以上即是引入微服务架构后带来的难点或缺点，供参考。自己也长期专注于SOA，微服务，DevOps支撑平台建设实施，欢迎交流。