我们在搭建一个系统的时候，通常需要考虑如何与其他系统进行交互，所以我们首先需要知道各个系统之间是如何交互的，是用什么技术来实现的。1、不同系统、不同语言之间的交互现在我们普遍使用WebService、Http请求来进行不同系统、不同语言之间的交互。WebService，即“Web服务”，缩写为WS。从字面上理解，它实际上是一种“基于网络的服务”。但服务是双向的，有服务需求者，也有服务提供者。服务提供者对外发布服务，服务需求者调用服务提供者发布的服务。如果更专业一点的话，WS其实就是一个基于HTTP协议实现异构系统通信的工具。这是正确的！说白了，WS还是基于HTTP协议的，也就是说数据是通过HTTP传输的。一开始我们用CXF开发SOAP服务来实现WS，后来用REST服务来实现WS（这个目前用的比较多，也是我用的最多的）。基于CXF也可以开发REST服务，但是我们一般直接使用springMVC或者其他MVC框架来实现REST服务。然而，在很多人的印象中，Web服务泛指IBM十多年前主导的各种基于XML的交互技术。现在除了一些公司，很少有人用。从广义上讲，Webservice就是Web服务，万物皆服务。2.不同系统和同一种语言之间的交互是通用的。不同系统和同一种语言之间的交互是通过RPC（RemoteProcedureCall）或RMI（RemoteMethodInvocation）实现的，不需要对外提供服务。当然上面也可以用同种语言之间的交互，不过我一般用RPC。不同产品的架构3.单个产品的架构演进通常我们只有一个产品的架构演进过程。如果我们需要对外提供webService，我们通常使用REST服务来实现。下面一段来自知乎1.分布式架构的演进。系统架构的演进——初级阶段。在架构初期，小系统应用程序、数据库、文件等所有资源都在一台服务器上，俗称LAMP特点：应用程序、数据库、文件等所有资源都在一台服务器上。说明：通常服务器操作系统使用linux，应用程序使用PHP开发，然后部署在Apache上，数据库使用Mysql，各种免费开源软件的集合和一台便宜的服务器就可以开始系统的开发。2、系统架构的演变——应用服务和数据服务的分离并没有持续多久。发现随着系统访问量再次增加，高峰期webserver机器的压力会上升到一个比较高的水平。这时候，我们开始考虑增加一个webserver。特点：应用程序、数据库和文件部署在不同的资源上。问题描述：数据量增加，单台服务器性能和存储空间不足。需要将应用与数据分离，并发处理能力和数据存储空间得到极大提升。3、系统架构的演进——使用缓存提升性能特点：将数据库中访问较为密集的一小部分数据存储在缓存服务器中，减少数据库访问次数，减轻数据库访问压力.说明：系统访问的特点遵循80/20法则，即80%的业务访问集中在20%的数据上。缓存分为本地缓存和远程分布式缓存。本地缓存访问速度更快，但缓存数据量有限。同时，与应用程序存在内存争用。4、系统架构的演进——使用应用服务器集群做分库分表的工作后，数据库的压力降到一个比较低的水平，开始过上幸福的生活watching访问量每天都在飙升。有一天，我发现访问系统的速度又开始变慢了。这时候先查了一下数据库，压力正常。然后查看了webserver，发现apache拦截了很多请求，应用服务器对每个请求也比较快。貌似是请求数量太多，导致需要排队等候，响应速度变慢。特点：多台服务器通过负载均衡同时对外提供服务，解决了单台服务器的处理能力和存储空间限制的问题。说明：利用集群是系统解决高并发、海量数据问题的常用方法。通过向集群中添加资源，提高系统的并发处理能力，使服务器的负载压力不再成为整个系统的瓶颈。5、系统架构的演进——数据库读写分离。在享受了一段时间系统访问量快速增长的快乐后，我发现系统又开始变慢了。这次是什么情况？查找后发现，数据库写入和更新这些操作中部分数据库连接的资源竞争非常激烈，导致系统变慢的特点：多台服务器通过负载均衡同时对外提供服务，解决了单台服务器的处理能力和存储空间限制的问题。说明：利用集群是系统解决高并发、海量数据问题的常用方法。通过向集群中添加资源，服务器的负载压力不再是整个系统的瓶颈。6、系统架构演进史——反向代理和CDN加速特性：利用CDN和反向代理加速系统访问。说明：为应对复杂的网络环境和不同地域用户的访问，通过CDN和反向代理加快用户访问速度，同时减轻后端服务器的负载压力。CDN和反向代理的基本原理是缓存。7、系统架构的演进——分布式文件系统和分布式数据库随着系统的不断运行，数据量开始大幅增加。这个时候发现分库之后的查询还是有点慢，于是开始按照分库的思路分表工作特点：数据库采用分布式数据库，并且文件系统采用分布式文件系统。说明：任何强大的单一服务器都无法满足大型系统不断增长的业务需求。随着业务的发展，数据库读写分离终将无法满足需求。需要使用分布式数据库和分布式文件系统来支持。分布式数据库是拆分系统数据库的最佳方式。只有在单表数据规模非常大的时候才会用到。数据库拆分比较常见的方式是业务分库，将不同的业务数据库部署在不同的物理服务器上。优越的。8.系统架构演进史——利用NoSQL和搜索引擎特性：系统引入了NoSQL数据库和搜索引擎。说明：随着业务越来越复杂，对数据存储和检索的要求也越来越复杂。系统需要使用一些非关系型数据库如NoSQL和分库查询技术如搜索引擎。应用服务器通过统一的数据访问模块访问各种数据，免去了应用程序管理众多数据源的麻烦。9、系统架构演进史——业务拆分特点：系统按业务拆分改造，应用服务器按业务分工分别部署。说明：为了应对日益复杂的业务场景，通常采用分而治之的方式将整个系统业务划分为不同的产品线。应用程序之间的关系通过超链接建立，数据分发也可以通过消息队列进行。当然，更多的是通过访问同一个数据存储系统，形成一个关联的完整系统。垂直拆分：将一个大应用拆分成多个小应用。如果新业务比较独立，那就直接设计部署成一个独立的web应用系统。垂直拆分相对简单。通过业务梳理，可以剥离较少的相关业务。水平拆分：将复用的业务拆分，独立部署为分布式服务。新业务只需要调用这些分布式服务即可。横向拆分需要识别可复用业务，设计服务接口，规范服务依赖。10、系统架构的演进——分布式服务特性：将常用的应用模块抽取出来，部署在分布式服务器上，供应用服务器调用。说明：随着业务越来越小，应用系统的整体复杂度呈指数增长。由于所有的应用程序都需要连接所有的数据库系统，最终会导致数据库连接资源不足而导致服务被拒绝。Q：分布式服务应用会面临哪些问题？(1)当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。(2)随着开发的深入，服务间的依赖关系变得复杂复杂，甚至分不清哪个应用先启动哪个应用，架构师也无法完整描述应用的架构关系。(3)然后，服务调用量越来越大，服务的容量暴露出来。该服务需要支持多少台机器？什么时候加机器？(4)服务越来越多，通讯成本也开始上升。某项服务调整失败应该联系谁？服务参数的约定是什么？(5)一个服务有多个业务消费者，如何保证服务质量？(6)随着服务的不断升级，总会发生一些意想不到的事情，比如缓存写入错误导致内存溢出，故障在所难免，每次核心服务挂掉，影响大面积，人心惶惶，故障影响如何控制边？服务能否在功能上降级？还是资源退化？这好像是《大型网站技术架构 核心原理与案例分析》开篇的内容，不过作者总结的很好，所以转载一下。4、另一种产品线结构就是上面提到的业务拆分。现在要做一个产品线，只需要一个数据层，一个通用的业务逻辑层，以及前面的各种应用层和接口层，不需要对外系统提供服务（外部公司的系统).选择使用EJB构建分布式应用，但是现在我们可以使用dobbo、thrift、avro、hessian等RPC框架构建分布式应用，实现不同应用和数据源之间的交互。在这种结构模式下，我们需要为其他公司提供服务，我们可以编写一个应用程序来对外系统提供rest服务。一般大多数互联网服务需要访问几十个甚至上百个内部服务，它们之间的通信方式一般是RPC：就像访问远程方法一样，输入参数，等待返回结果。这是理解复杂系统的最简单方法。下图中的模型、文件系统、缓存没有画出来，大家可以看懂。结语：不管是什么架构，我们都需要做好模块化（尽量做到模块复用）。不要为了架构而架构，这会导致过度工程。无论什么样的架构是为了更好的满足业务需求，架构都应该随着业务的发展而发展。如果现在的架构能够满足现在的业务发展，就可以考虑下一步的扩展，而不是一下子考虑3步、4步甚至更多。以上如有错误，还望大家不吝赐教！
