软件架构简介

        软件架构（software architecture）是一系列相关的抽象模式，用于指导大型软件系统各个方面的设计。

一、定义

        软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。在面向对象领域中，组件之间的连接通常用接口来实现。

        软件体系结构是构建计算机软件实践的基础。举个栗子，栗子是用来看的不是用来吃的哈，吃货观众们，口水收收，先学习。

        没盖过房子，我想，大家都看过盖房子吧，特别是楼房。首先，选一片地方，然后打地基，搭建楼房的架子，再慢慢刷墙，贴瓷砖等等。这个过程跟软件架构师是一样的，先做出一个软件的框架来，然后不断完善软件代码。

二、目标

        架构设计要达到的目标是什么呢？一般而言，软件架构设计要达到如下的目标：

        可靠性（Reliable）。软件系统对于用户的商业经营和管理来说极为重要，因此软件系统必须非常可靠。

        安全性（Secure）。软件系统所承担的交易的商业价值极高，系统的安全性非常重要。

        可伸缩性（SCAlable）。软件必须能够在用户的使用率、用户的数目增加很快的情况下，保持合理的性能。只有这样，才能适应用户的市场扩展得可能性。

        可定制化（CuSTomizable）。同样的一套软件，可以根据客户群的不同和市场需求的变化进行调整。

        可扩展性（Extensible）。在新技术出现的时候，一个软件系统应当允许导入新技术，从而对现有系统进行功能和性能的扩展。

        可维护性（MAIntainable）。软件系统的维护包括两方面，一是排除现有的错误，二是将新的软件需求反映到现有系统中去。一个易于维护的系统可以有效地降低技术支持的花费。

        客户体验（Customer Experience）。软件系统必须易于使用。

        市场时机（Time to Market）。软件用户要面临同业竞争，软件提供商也要面临同业竞争。以最快的速度争夺市场先机非常重要。

        这块概念我想大家应该都比较了解，就不多详细说明啦。

三、常见架构分类

1. 分层模式（三层架构）

        这种模式也称为三层架构模式。它可以用来构造可以分解为子任务组的程序，每个子任务都处于一个特定的抽象级别。每个层都为下一个提供更高层次服务。一般信息系统中最常见的是如下所列的3层。

        表示层(也称为UI层)

        业务逻辑层(也称为领域层)

        数据访问层(也称为持久化层)

2.客户端-服务器模式

        这种模式由两部分组成：一个服务器和多个客户端。服务器组件将为多个客户端组件提供服务。客户端从服务器请求服务，服务器为这些客户端提供相关服务。此外，服务器持续侦听客户机请求。

        这种就比较常见了，或者说很常见，就在我们身边，我们用的QQ，手机淘宝，支付宝，优酷客户端等等，都是这类模式的典型代表。

        这种模式有一个很洋气的名字，我们称之为C/S架构。

3.浏览器-服务器架构

        这种架构也称为B/S架构，它是随着Internet技术的兴起，对C/S架构的一种变化或者改进的结构。在这种结构下，用户工作界面是通过WWW浏览器来实现，极少部分事务逻辑在前端(Browser)实现，但是主要事务逻辑在服务器端(Server)实现，形成所谓三层3-tier结构。B/S架构是WEB兴起后的一种网络结构模式，WEB浏览器是客户端最主要的应用软件。这种模式统一了客户端，将系统功能实现的核心部分集中到服务器上，简化了系统的开发、维护和使用。

        我们每次上网逛得那些不为人知的小页面啊，广为人知的小页面啊，大多数都是这种架构的。

4.微服务架构

        微服务架构是一项在云中部署应用和服务的新技术。大部分围绕微服务的争论都集中在容器或其他技术是否能很好的实施微服务，而红帽说API应该是重点。

        微服务可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。

        说的这个概念有些深奥了，从我个人理解来看，你可以想象一下积木，每一个积木块都是一个独立的个体，虽然有时候每个积木必不可少，但是如果一个积木丢失或者损坏，只需要立马补上这一个积木块就可以了，不需要将整体积木全部更换或者维修。微服务就是如此，它将一个大型的项目分解成不同的小块，通过相互之间的接口调用或者继承来实现相关的联系，从而实现整体功能，但是有一个功能模块更新，或者出现问题，只需要修改这个模块即可，很少会影响到整体。

5.响应式架构

        关于响应式架构，我不想找网上的定义了，只是想在这里，跟大家一起分享我自己的理解和看法，也希望对架构有了解，有兴趣的同学一起讨论，一起交流。

        从名字来看，响应式架构是什么呢？就是我叫了某一个人的名字，他回应了我，他的这个行为就是对我的行为的响应。包括JAVA里面有事件监听，就是程序对你触发鼠标或者键盘事件的一个响应。

        响应有什么好处呢？我叫了你，你可以不用回应我，我去做别的事，我叫你只是我完成了我的事件，你随时都可以响应我，只不过我着急的时候，我会催你，再给你发第二个事件，等你响应。这个期间，我可以先去做别的事情。如果没有相应式，我会一直等你，等到我死（系统崩溃）当然，异常处理能够解决大部分的问题，如果触发异常，计算机会自动采取一些行动来退出，防止系统崩溃。但是，程序员不能保证在所有的可能出错的地方都设置异常处理，他们应该把更多的精力放在如何让程序更加完善上。鲁棒性只是其中一部分，所以响应式应运而生。所有的接口调用，信息传递等都采取响应式。可能会在一定程度上减缓程序的效率，但是可以大大的增加系统的鲁棒性。

        在响应式方面，做的最好的应该是基于Scala语言的akka框架，当时了解到这个架构的时候，小编还从网上找资料学过一些Scala。Scala和Java比较相似，但是我认为Scala还是更强大一些，是因为Scala支持函数式编程。如果不是对C++有深沉的爱，对数学有深沉的爱，我想，我已经踏上Scala之路了。

        扯得有些远啦，让我们再扯回来，在akka框架中还应用到了分析模式，话说，我看了5个月的分析模式，也没有弄懂相关的概念，还是太年轻啊。在这方面有一本书不错，推荐给大家：《响应式架构：消息模式Actor实现与Scala,Akka应用集成》这本书将带领你通过Actor模型使用响应式消息传输模式，编写出具有高性能、高响应性、高可伸缩性和高韧性的并发应用程序。当然，如果你还是一个编程小白，我的建议是你可以简单看看这本书，对书中的概念有个印象，然后多做项目，多做项目，多做项目。架构思想，编程思想，不是你看书看几次就能学会的，是通过积年累月的项目经验和自己的不断总结得出来的。