论软件工程

昨天一位同学问我对软件工程的体会时愣住了一下，不知道该怎么回答，感觉话到嘴边却不知道怎么表达，因为这个话题比较沉重，不知道该怎么用简短的语言来进行描述，要说可能一天都说不完，可能是自己的表达能力有限，语文没学好（高考语文不到80分），当时只是给出了：“这叫我怎么回答”这样的答案。随后在我的脑海里一直回忆自己开发经历，想从中找到一些信息。第一次听到软件工程是大三的时候有一门课程叫做软件工程，我依稀记得里面几个关键词语：髙聚类.低耦合、可扩展性、可行性、可维护性，同时还包括一些软件开发过程。下面将结合这几点以及我的经历来谈谈我眼中的软件工程，同时也对自己进行一次总结。

髙聚类.低耦合

这个词是自从我上过软件工程的课之后一直没忘记过，并且一直影响这我着设计开发过程。什么叫髙聚类句话就可以概要：物以类聚，人以群分。什么意思是将相同属性的事物抽离出来，从而简化对这一类事物的控制，以方便管理。那什么叫低耦合面说了将相同属性的事物抽离出来以达到分组，那么低耦合就是降低各个分组之间的关系，这样可以达到结构清晰，管理灵活。上面都是解释字面上的意思，完全没有扯到一点关于软件方面的东西，那么这两个词放在软件设计里面是怎么体现的呢/p>

这个可以分为宏观和微观，宏观上面，一句话：模块化，层次化。模块化和层次化是髙聚类和低耦合在软件设计宏观上面的体现，具体的又可分为纵向业务划分，和横向架构划分（这也称为二维架构，之前还听过蔡学镛老师说的四维架构这个就更加的抽象了）。将相同业务抽离到一个模块里面，将整个业务线切分成多个层次,上层只能依赖下层，下层不能依赖上层的图结构。从而使得整个软件在结构上层次分明，业务线清晰。这里举个例子：比如我现在要做一个电商 站，首先要做的第一件事情不是探讨技术上面是否有难点，而是探讨整个 站业务方向，从而确定整个业务模型，对里面进行建模，分析里面包含的哪些领域模型。先不谈复杂的电商，就说一个初期的C2C 站，首先它的业务方向是一个个人买家交易平台，一个用户即可以扮演买家也可以扮演卖家，确定这个之后，我们再对里面进行建模，从而可以进行模块划分。上面的 站可以简单划分为商品模块，订单模块，用户模块等等，那么这个模块就是在软件架构里面的髙聚类，那么低耦合怎么体现呢块划分之后需要确定模块在整个系统里面的定位，从而可以确定它们之间的依赖关系，以达到确定它们所处的层级。下面通过一个图来描述上面三个模块的层次关系：

整个通信过程是将处理结果告知，然后将结果告知当作任务放入本地一个队列中，然后有一个线程专门处理这个队列的任务将结果告知。这种架构存在什么缺陷呢下面列举一下：

1. 存在单点过障，如果流量增加单台可能根本处理不过来整个业务
2. 存在集群部署的障碍点，是将任务放在本地的内存里面，如果集群部署分担压力，那么在本机的任务其他服务器根本无法感知导致无法分担压力
3. 没有很好的模块划分，将接受系统A的和转发系统B的代码全部杂糅在一起，导致后面对系统进行扩展很难
4. 存在数据丢失场景，如果系统上线新版本，服务重新部署，那么缓存在内存里面的任务如果挤压很多一时处理不完，那么重启必然导致内存里面的任务数据丢失，导致不能再通知

针对上面几个问题我提出了下面的解决方案，先看看改进后的拓扑图：

将原来系统拆分成两个模块，一个是和，然后这两个模块之间通过异步的MQ来进行通信，现在的执行流程是：将处理结果发送给转发系统的前置Nginx，Nginx将请求通过负载均衡到后端具体服务器上，某台服务器即受到处理请求之后，将结果受理并执行相关业务，然后将通知任务放入的消息队列中，这个时候可以立马响应结果给，这个时候通知处理结果就处理完毕，最后再就是由于监听了的消息队列，那么如果有任务消息过来，将会接收到，此时将结果发送给。这个时候接受处理结构模块的吞吐量增加了，处理能力也增加了，因为将任务不再是缓存在本地，而是放入中，那么它是无状态的，可以随意水平扩展，从而可以应对高并发的业务处理。而通知由于是监听中的消息队列，业务压力上来并不会给它带来压力，它依然按照它的节奏在处理任务，如果想让处理速度快一点，可以在集群中多部署几台机器来解决，这样使得整个系统的水平扩展方面得到了很大的提高，也使得整体系统的处理效率以及系统结构得到一定的优化。

可能有人会说，我这样把一个简单的系统拆分成这么多模块，把整个项目弄得复杂了，需要维护和管理这么多模块，同时还加了一个MQ的维护。当然这么拆分的前提条件是你的业务量上来了，或者为以后做准备，如果你现在的系统一天才处理不到一万个请求，我也建议没必要这么搞。但是如果作为一个可以持续发展的项目，前期很好个规划可以很好的避免后面的大规模重构。上面这种方案对于实时性要求很高的系统也不是很适合，因为MQ是异步的，所以存在一定的延迟，所以对于允许有一定延迟的业务可以采用MQ来提高整条业务的响应速度，以达到业务处理的吞吐量，当然这里所指的延迟并不是延迟几个小时，这种延迟一般不会超过一分钟。

在我们现实生活中这这里模式也很多，比如我们刷银行卡，然后我们手机立马会收到银行一个短信通知我们有一笔消费，一般从你刷卡到你收到短信不会过太久就会收到短信，这个过程总就涉及到异步处理。它这里的流程一般是这样的：一般你刷卡处理的后台系统是银联（当今中国线下清结算老大，线上你们都应该知道），银联通知对应银行对某张卡进行扣款（里面具体的操作我也不太清楚，一般做法是银联通知对应银行将钱转到银联的一个账 上，然后商户和银联进行结算），银行将扣款结果通知给银联，这个时候银行也会将一条短信存储在一个类似消息中心中，并有专门的系统处理这些消息去通知用户，银联在返回给POS机，最后POS机出票，这个时候手机也会收到一条银行短信。在这个过程中银行生成短信并不是立马去发送，而是放入消息中心（这个类似于一个MQ），让其他系统异步去做，为什么要这么做呢为发送短信并不是业务主线内容，如果扣款和发送短信放在一起同步去做，那么会导致整个业务响应很慢，也可能由于短信发送失败导致整个业务失败，因为发送短信谁能保证百分之百的成功，而且谁能保证百分之百的快速响应以将这种附加在主业务分支上的业务通过异步执行来提高整条业务的成功率和处理效率，这也是企业级系统开发常用的手段。

以上是我所认识的软件工程，也不知道最后表达了什么思想，只是总结了一下到如今我对软件开发的一个认识。以上也是我主观的认识，并不具备参考意义，还望不要误导大家。