1 引言
笔者从事架构师工作多年，发现虽然软件开发人员人人都知道架构，但架构真正做什么，确很少有人能说的清楚。
大部分普通开发人员所想到的架构是框架的搭建以及各种架构技术比如缓存、消息队列、多线程等等，笔者曾经面试过一个应聘架构师岗位的面试者，询问他所做过的架构工作，当时面试者给的答案只是他们所开发系统的脚手架是他搭建的。
也听不少开发人员说他们的系统就是没有架构的，没有架构也能够做系统，那架构在其中起到一个什么作用？
笔者在平时的工作中也遇到过不少对架构不慎理解而引起的问题，本文不介绍架构的方方面面，只是结合这些问题浅谈下架构。
2 日常工作中的架构问题
2.1 架构视角
有个系统，架构师做完架构设计后，召集相关人员做了一个架构评审，当该架构师做完设计介绍后，领导和非软件开发人员对其是满意的，但是在会几乎所有做软件研发同事都表示没办法做，因为按照这个设计研发完全不知道应该怎么去开发这个产品。
当时软件研发同事能够知道这个设计是有问题的，但却无法说出具体问题在哪里，只知道按照这个设计他们无法入手去做。其实从架构的角度来说，问题是出在所占视角不同。
该架构师当时的设计更类似于系统的架构愿景，描述了做完以后这个系统是怎么样子的，包含了哪些功能，这样的设计适合给领导和客户演示使用，或作为一个开发需求和设计的入口，但如果说这样就设计完了，那开发是完全无法入手的。
因为他未从开发人员的视角去设计系统，该系统其实会和很多的外部系统进行交互，但从他的设计中开发人员无法知道这个系统应该和那些外部实体如何交互、交互内容是什么和协议是怎样的，也不知道这个系统应该划分为哪些子系统（或模块）、各子系统关系怎样、如何交互、系统各需求应该放哪个子系统去实现、以及各子系统都应该采用什么语言什么框架什么技术去开发？
在进行系统的架构设计时，其实不同的相关人员所关心的问题不同，在架构师进行架构设计时，需要考虑为不同相关人员的视角设计不同的架构视图。包括用户视角、领导和客户视角、开发者视角、部署视角等等。
2.2 消息中间件架构师的工作职责
笔者之前公司在决定使用KAFKA消息中间件之前，软件总监曾经安排一个同事学习和并测试下KAFKA性能，而当时那个同事测试出来KAFKA性能只有几百条每秒，后来公司招了一个KAFKA架构师，能够达到很高性能（具体多少忘记，KAFKA收发性能一般能达到几万条每秒以上），总监很满意，于是安排其给某个项目引入KAFKA出个解决方案。 当方案出了后，当时那个项目组成员意见很大，因为该架构师只是搭建了KAFKA服务器，以及给了IP端口，以及演示了客户端如何接入KAFKA服务器，但该项目组原先没有架构师同时也没有用过其他消息中间件，所以不知道如何入手。
每个公司对于中间件架构师的工作职责要求可能不一样，但该项目组其实是希望该架构师能够给他们系统改造，出个整体的解决方案，而不仅仅只是搭建和维护好KAFKA服务器（即能够分析下他们系统，能够给出他们系统原先架构是怎样的，引入KAFKA后架构是怎样的，指出他们系统哪些地方需要改动，做哪些改动，哪些地方需要作为消息生产者将消息发送到消息中间件服务器、哪些地方需要作为消费者接收消息进行消费处理、另外告诉他们收发TOPIC、数据内容格式、消费者数量多少，是否需要分区如何分区、客户端参数如何配置等）。
2.3 需求放哪里实现
2.3.1 需求分解分配
2.3.1.1案例
某数据平台会对设备数据进行采集，并进行处理后得到最终的业务需要的数据分发给多个第三方公司业务系统。该平台有数据采集、数据处理、数据分发、数据服务、基础数据管理和监控WEB平台（以下简称监管平台）等等多个子系统组成。其中监管平台是WEB平台，给用户进行管理监控数据分析等操作使用；而其他几个是后台运行的JAR包，处理高并发数据的采集处理分发。
考虑到该平台后续会用于项目中，会和很多不同的第三方公司业务系统进行对接，而这些第三方系统的接入协议通常也不同，为了减少平台研发组的人力投入，后续让项目组自己定制开发对接协议，并且不会影响到其他部分代码。该平台研发负责人（也是架构师）决定对数据分发子系统做下改造，改成插件形式，数据分发子系统需要给哪个第三方系统分发数据时只要加载对应转发插件，然后调用插件的方法进行数据协议封装和发送。
于是该负责人安排了研发组一个同学进行这部分的改造开发，考虑到该同学已经有6年研发经验并有2年大厂经验，所以并未给该同学出设计方案，而是由该同学自己出设计方案。
在监管平台中原先有个对接管理模块，管理与第三方系统的对接配置信息（比如对接标识、企业名称、接入地址、接入账号密钥、支持协议类型）和对接数据配置，该负责人原想该同学应该会在该WEB平台对接管理模块中加入一个插件管理页面。但该同学在设计时在分发子系统中加入了TOMCAT，将数据分发子系统改成了WEB系统，然后将插件管理做在了数据分发子系统的WEB页面中。
2.3.1.2带来的问题
他的详细设计方案已经忘记，这里说明下这样的设计带来的问题：
问题1：数据平台本来只有监管平台一个WEB管理平台，该同学这样设计后管理页面的入口就有多个，用户需要去记多个管理后台的IP和端口，降低了系统的可维护性；
问题2：监管平台会对使用平台和APP的用户进行身份验证和权限控制。而新增加的WEB系统没有登录功能，没有权限控制，插件管理的访问安全完全无法保证。
问题3：后续系统的开发人员需要在两个地方去维护管理功能，降低了系统的可修改性。
2.3.1.3架构讨论
该同学这样做的可能原因时因为他接收到的需求是对数据分发子系统进行插件化改造，所以觉得这些功能都应该是做在数据分发子系统之中。
架构设计很多时候做的是需求的分配，我们在做架构设计时会将一个复杂的系统划分为相对简单的模块（或子系统），而架构工作要做的就是将需求进行分解并分配到合适的模块中。
当我们的需求分配到不合理的模块中去实现时就会引发各种问题，比如难于维护、难于扩展、引发安全、性能问题等等。
对于转发服务插件化这样一个需求，我们首先要做的就是对需求进行分解，该需求可以分解为四个子需求：
需求1：插件开发（包括插件接口、插件模板）
需求2：插件管理
需求3：对接管理中加入使用的插件
需求4：数据分发子系统中改用插件与第三方系统进行对接
然后要对需求进行分配，比如插件开发是单独的JAR包开发，插件管理和对接管理中加入使用的插件分配到监管平台的对接管理模块中进行开发，数据分发子系统中改用插件与第三方系统进行对接，则分配到原数据分发子系统中进行改造开发。
该同学做了需求分解，但却未将子需求分配到合适的子系统中去实现。
2.3.2 高内聚低耦合
2.3.2.1案例
某项目是一个前端设备数据采集系统由数据采集、数据处理、数据转发三个子系统组成，在该项目上线多年后客户提了一个需求对一个传感器信号数据处理进行修改，当时负责该项目运维的同学在了解了系统情况后，决定将该需求放在数据转发子系统中去实现，因为他们觉得数据处理子系统很复杂，他们怕改错，而数据转发子系统他们觉得结构比较清晰，只要放在给第三方发送数据前的数据格式封装JAVA类文件那里修改就可以了，很简单。
2.3.2.2带来问题
如果只是从实现客户当时提的那个功能需求的角度，该需求不管放数据处理子系统还是转发子系统中实现都是可以的，但从架构角度该做法是不允许的，架构设计做的是把一个复杂的系统划分成多个简单子系统的组成，每个子系统的功能都会相对比较单一和清晰，让子系统内部功能高内聚而子系统间耦合度降低，这样整体的系统的开发维护才能变得简单。
因为这样的做法会带来一些问题：
1） 可维护性问题
在该项目中数据处理子系统做数据处理的事情，数据转发子系统做第三方系统的连接管理、数据协议解析、封装、数据发送的事情，如果他们把数据处理放到了数据转发子系统去实现，那也就失去了原先子系统划分的意义，以后接手的同事不清楚就会很难去维护；
而这几个同学觉得该需求放转发子系统中实现会很简单，也是因为转发子系统重构过该子系统中模块划分很清晰，协议封装类文件中只做协议封装的事情（该开始他们觉得转发子系统是很复杂的因为有很多线程，觉得很不容易做稳定）
2） 可复用问题
这个项目最初开发时是从另一个收费的业务系统改造而来，对于数据采集前端而言，该项目功能是不齐全的，缺少了设备管理、监控、设备数据调试等等功能，该项目的数据处理子系统用了公司同事都不怎么熟悉的glassfish应用服务器。
在我们公司内部其实很多项目功能都有很多类似的地方，基本都有设备数据采集、数据处理的功能，而数据处理的方法都类似（即使是该项目新添加的这个需求，在其他项目中也是适用的）。由于老的系统的不合理及问题多，公司研发团队也在开发新的产品。后续如果新产品开发完成，该项目的数据采集和数据处理子系统完全可以用新产品的数据采集、数据处理子系统及监管平台代替，而只保留数据转发子系统（该项目数据转发第三方协议和其他项目相差较大）。
但是如果在这个数据转发子系统中加入数据处理的功能，那如果数据处理子系统替换掉，该需求中的数据处理就做了两次就会有问题，如果到时做替换的同学不了解情况，就会有问题。
这个需求放哪里实现其实说起来很简单，但却是开发维护过程中普通开发人员经常会犯的问题，很多普通开发人员为了追求速度，只要把功能实现没BUG就好，而不管后面维护是否会变困难。有些系统越维护越复杂，到最后没人敢动只能重构，很大的原因就在这里。
2.4 日志问题
笔者曾经接手一个经常宕机的项目，该项目几年运行下来每个子系统的日志文件只有一个，当笔者想要打开日志文件排查问题时发现由于日志文件过大完全打不开，相当于日志写了等于没写，该项目需要和设备端对接也需要和第三方公司进行对接，由于日志不完善及实际也看不了日志，所以当某个数据出现问题时因很难定位问题经常会出现扯皮想象。笔者当时对这个系统的日志进行了一些改造，出现问题时都能够很快速排查和定位到问题，之后再没出现扯皮想象。
日志其实对于问题排查和数据分析统计至关重要。一些大型系统会通过消息中间件或FTP将日志发送到专门的日志系统进行分析，比如运营商短信网关专家系统等。而小型系统中通常也会使用日志框架对日志进行记录，为了方便排查问题和考虑日志文件大小按每日或每个小时记录一个日志文件，并按年份或月份等放不同文件夹中，另外对一些关键模块和错误日志也都会另外单独弄日志文件。同时要对日志分级别，比如错误日志、告警日志、常规信息、调试日志等。
另外系统放到线上后打印日志级别要是常规信息日志级别以上，如果开了DEBUG日志要及时关闭，这个在一些大企中都是作为一个安全需求要进行检测的，因为如果DEBUG日志打开，则系统需要耗费更多的资源去记录日志，黑客可以不停的给系统发送消息，让系统资源耗尽而引发故障。
日志的记录对于系统的可维护性和安全性都至关重要。
2.5 性能优化
曾经有几个其他项目组同事找我，问我我们平台给第三方转发数据性能如何，他们项目给第三方转发数据性能只有2-3条/秒，并发量比较高或某种网络条件下会出现宕机情况。我感觉很奇怪，转发没什么耗时的操作一般每秒发送几百几千条问题都不大。后来看了下他们的代码才发现原因：
- 他们发送采用了同步方式
- 他们使用了短连接（每次发送完都会去关闭连接）
他们每次发送完消息都是等待对方返回后才会去发送下一条消息，因此性能很差，而且受网络和第三方公司系统性能影响很大，为了提高并发量，他们采用了线程池，虽然能提高性能，但是使用多线程会增加系统开销，也因此他们的CPU通常都配置的很大（几万个传感器发送大概几十秒/条数据一般都配置了16核CPU）。
其实他们这里只要做两步修改，性能就可以大幅提高：
- 同步改异步
- 短链接改为长连接
同步改异步
给第三方系统发送完消息后，不等待对方返回，直接发送下一条消息，这样性能就会大大提高，受网络环境和第三方系统性能影响也会大大降低，不需要多线程发送，也就不需要配置高核CPU。而为了接收对方的返回以便进行后续的处理，可以给每条消息都加上唯一序列号，同时将已发送消息放到已发送消息队列中，从对方接收到返回消息后，从已发送消息队列中获取对应消息进行处理。
短连接改为长连接
长连接的好处是可以减少tcp连接的开销，一般我们认为TCP协议是长连接，HTTP协议是短连接，但HTTP协议基于TCP协议之上的应用层协议，其本身对长连接(KeepAlive)是支持的，其中HTTP1.0需要在request中增加"Connection： keep-alive" header才能够支持，而HTTP1.1默认支持。
做这样的性能优化后支持同样的传感器数量，该系统由原来需要配置16核CPU到只需要使用2核CPU，并且平时也只占用到15%左右。
多线程能解决性能问题吗？在大多数情况下多线程可以提高系统的性能，但在这里却不是解决问题的最合适的方法。
2.6 架构模式
笔者曾经负责一个云平台的设计，我们将该平台分为了多个可以独立部署运行的应用组成，一共有20个左右的应用（比如用户中心、积分平台、财务中心、商户管理系统、停车场管理系统、运营管理系统、用户分析系统、数据服务系统、权限、日志、统一配置、任务调度、短信中心、安全中心等等），每个应用都有自己独立的数据库，笔者设计了每个应用的功能、上下文、内部架构、对外接口等等，但我在对具体接口流程进行设计时却犯了难，为了安全起见是否我每个接口调用时都需要进行鉴权？鉴权和记录日志先后顺序应该怎样？我是否需要创建专门的监控系统监控所有应用的运行情况，这么多应用都各自做集群或双机……后来看到了微服务架构，很多问题也就迎刃而解。不用每个接口调用都去鉴权，而是所有接入都先到一个安全网关，在安全网关可以进行权限管理、访问控制和流量限制。所有服务注册到服务注册中心，服务和服务注册中心直接维持心跳，这也解决了应用的监控问题。另外像统一配置微服务框架中都已经考虑到……
这里的微服务架构其实是一种架构模式，架构模式（架构风格）是描述某一特定应用领域中系统组织方式的惯用模式，一个架构模式描述软件系统里的基本的结构组织或纲要。架构模式提供一些呈现定义好的子系统，指定它们的责任，并给出把它们组织在一起的法则和指南。
在我们的日常工作中，为了解决比如高并发访问、高可靠运行、海量数据处理、运维工作量等一系列问题与挑战，开发人员在实践中提出了很多解决方案，有些方案也成为了解决某类问题的惯用模式，比如分层分割、分布式、集群、缓存、冗余、异步、自动化、安全、微服务等，这些就形成了架构模式。
3 软件架构是什么
软件架构为软件系统提供了一个结构、行为和属性的高级抽象，由构件的描述、构件的相互作用、指导构件集成的模式以及这些模式的约束组成。软件架构不仅显示了软件需求和软件结构之间的对应关系，而且指定了整个软件系统的组织和拓扑结构，提供了一些设计决策的基本原理。
软件系统属性包括功能属性和质量属性，质量属性也称为DFX属性（非功能属性），软件架构重点关注的是质量属性。架构的基本需求是在满足功能属性的前提下，关注软件系统的质量属性。这些质量属性主要有：性能、可靠性、可用性、安全性、可修改性、可维护性等。
软件架构就是架构师为了满足系统功能属性和质量属性，如何将复杂的系统切分成N个低耦合的子系统（或模块），然后将需求分解分配到各个子系统，再通过他们相互关系组成一个整体，完成系统的整体目标。
标签：插件,架构,浅谈,系统,日志,数据,子系统 From： https://www.cnblogs.com/haleylan/p/17641152.html