1、项目架构
 
 
前后端时候分离
 
 
 
是
 
 
后端使用的框架
 
 
 
Django-restframwork + celery
 
 
前端使用的框架
 
 
 
vue
 
 
数据库选择
 
 
 
mysql+redis
 
 
缓存实现
 
 
 
Redis
 
 
服务部署
 
 
 
基于Ubuntu的单机部署/ 基于docker-componse的一键部署
 
 
代码管理
 
 
 
Git
 
 
2、数据库设计
 
 
3、集成测试
 
测试阶段留意测试反馈平台的bug报告

 
文章目录
 
系统架构演化历程
单体架构
应用服务和数据服务分离
缓存的使用
集群的使用
数据库读写分离
反向代理和CDN加速
分布式文件和分布式数据库
NoSql和搜索引擎
业务拆分
分布式服务
 


   现在出去找工作如果不会点分布式和微服务相关的内容，都不太好更面试官扯蛋。但这些架构也不是突然就出现的，而是经过不但演变才出现及流行起来的，本文就给大家来梳理下java项目架构的演变历程。
 
系统架构演化历程
 
单体架构
 
  大型网站都是从小型网站发展而来的，网站架构也是一样，是从小型网站架构逐步演化而来的，小型网站最开始没有太多人访问，只需要一台服务器就绰绰有余了，这时的架构如下:
 

   应用程序、数据库、文件等所有的资源都在一台服务器上，通常服务器操作系统使用Linux、应用程序使用java或者其他语句，然后部署在Apache或者Nginx上。数据库使用MySQL，使用开源的技术实现，然后部署在一台廉价的服务器上就开始了网站的发展之路。
 
应用服务和数据服务分离
 
  好景不长，随着公司业务的发展，一台服务逐渐满足不了需求，越来越多的用户访问导致性能越来越差，数据存储空间开始不足，这时我们需要将应用和数据分离，分离后开始使用三台服务器：应用服务器、文件服务器、数据库服务器。如图:
 
 
  应用和数据分离后，不同特性的服务器承担着不同的服务角色，网站的并发处理能力和数据存储空间都得到了很大的改善，支持网站业务进一步发展，但是随着用户逐渐增多，数据库压力越来越大，访问延迟，进而影响整个网站的性能，此时需要进一步优化。
 
缓存的使用
 
  网站访问有个著名的二八定律，即80%的业务集中访问在20%的数据上，如果我们将这一小部分的数据缓存在内存中，能够很好的减少数据库的访问压力，提高整个网站的数据访问速度。
 
 
  缓存常用的组件可以是Redis,ehcache等
 
集群的使用
 
  缓存解决了数据库访问量比较大的问题，但是并不能解决随着业务增多造成的服务器并发压力大的问题，这时我们需要增加一台应用服务器来分担原来服务器的访问压力和存储压力。如图:
 
 
  通过负载均衡调度服务器，可将来自用户的访问请求分发到应用服务器中的任何一台服务器中，这样多台服务器就分担了原来一台服务器的压力，我们只需要注意会话的一致性就可以了。
 
数据库读写分离
 
  系统正常运行了一段时间后，虽然加的有缓存，使绝大多数的数据库操作可以不通过数据库就能完成，但是任然有一部分的操作(缓存访问不命中，缓存过期)和全部的写操作需要访问数据库，当用户达到一定规模后，数据库因为负载压力过大还是会成为系统的瓶颈，
   这时主流的数据库都提供的有主从热备份功能，通过配置两台数据库实现主从关系，可以将一台数据库服务器的数据更新同步到另一台服务器上。可以利用这一功能来实现数据库读写分离。从而改善数据库的负载压力，如图:
 
 
  mysql的读写分离可以通过自身自带的从主复制实现，Oracle的话可以通过阿里巴巴的mycat组件来实现。
 
反向代理和CDN加速
 
  为了应付复杂的网络环境和不同地区用户的访问，通过CDN和反向代理加快用户访问的速度，同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存。CDN部署在网络提供商的机房。用户请求到来的时候从距离自己最近的网络提供商机房获取数据，而反向代理则部署在网站的中心机房中，请求带来的时候先去反向代理服务器中查看请求资源，如果有则直接返回。如图：
 
 
  使用CDN和反向代理的目的都是尽早返回数据给用户，一方面加快用户的访问速度，另一方面也减轻后端服务器的负载压力。
 
分布式文件和分布式数据库
 
  任何强大的单一服务器都满足不了大型网站持续增长的业务需求。数据库经过读写分离后，从一台服务器拆分成两天服务器，但是随着业务的增长后面依然不能满足需求，这时我们需要使用分布式数据库，同时文件系统也一样，需要使用分布式文件系统。
   分布式数据库是数据库拆分的最后的手段，只有在表单数据规模非常庞大的时候才使用，不到不得已时，我们更常用的手段是业务分库，将不同的业务数据部署在不同的物理服务器上。
 
 
NoSql和搜索引擎
 
  随着业务越来越复杂，对数据存储和检索的需求也越来越复杂，这时一些NoSQL(Reids,HBase,mongodb)数据库技术和搜索引擎(Solr,Elasticsearch)的时候就显得很有必要。如下图:
 
 
  NoSQL和搜索引擎对可伸缩的分布式特性具有更好的支持，应用服务器通过一个统一的数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。
 
业务拆分
 
  当访问量达到一定规模的时候我们可以通过分而治之的手段将整个系统的业务分成不同的产品线，例如我们将系统的首页，商铺，订单，买家，卖家，支付，订单等拆分成不同的产品线。
   具体到技术实现上，也可以根据产品线划分，将一个网站拆分成许多不同的应用，每个应用独立部署维护，应用之间通过RPC框架(dubbo,webService,httpClient…)建立连接，也可以通过消息队列实现异步分发处理。来构成一个完整的系统，如下图:
 
 
分布式服务
 
  随着业务拆分越来越小，存储系统越来越庞大，应用系统的整体复杂度呈指数级增加，部署维护越来越困难，由于所有应用要和所有数据库系统连接，最终导致数据库连接资源不足，拒绝服务。
 
当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。
当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。
接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？
服务多了，沟通成本也开始上升，调某个服务失败该找谁？服务的参数都有什么约定？
一个服务有多个业务消费者，如何确保服务质量？
随着服务的不停升级，总有些意想不到的事发生，比如cache写错了导致内存溢出，故障不可避免，每次核心服务一挂，影响一大片，人心慌慌，如何控制故障的影响面？服务是否可以功能降级？或者资源劣化？
 
解决方案：公共的应用模块被提取出来，部署在分布式服务器上供应用服务器调用。也就是我们将的分布式服务或者微服务。
 
微服务的设计原则参考此文:
 https://dpb-bobokaoya-sm.blog.csdn.net/article/details/87305626

 
注意！！出于有关规定只能大致展示该项目架构图 望谅解

作为一个移动端开发人员来讲，是很难接触到后端项目架构的，所幸，从2015年开始，负责部分管理工作，参与了项目架构相关的工作。项目从小到大，架构也越来越复杂，特别是最近做的一个跨国型项目，涉及到国内国外服务器的部署，尤为复杂。本文结合这些项目实践，介绍基于阿里云的后端架构设计。（部分内容为引用他人的文章，文中已有说明，咱是尊重版权的）
 
 

 

 

 

 

 

 1.基础架构：

 2015年初，团队做了一个美食项目，业务逻辑比较简单，主要是实现用户、餐馆、美食三元素的增删改查及三者之间的关联查询。后端程序采用的是php，前端面对的是iOS和Android两款App。当时购买了一台阿里云ECS服务器，在该服务器上安装了MySQL以用于数据存储。应用程序、数据库、文件等所有资源都在一台服务器上，网站架构如下图所示：

 

 

 
 
 

 
 

 此架构简单，适用于项目初期，访问量比较小情况。这里着重要说一下的是，此项目中涉及到资源文件的存储但并没有用到OSS服务器，我们的做法是在客户端在上传图片文件的时候，接口程序会将图片压缩为所需的多种尺寸，并保存在对应的文件夹下，前端再取图片的时候在URL后拼接对于的尺寸即可访问。如客户端上传了一张图片，程序会压缩为30*30，120*120，240*240三种尺寸，客户端根据界面需要采用xxxxx_30.png的方式访问，这个功能在阿里云的OSS服务器上有现成的服务，无需自己压缩。

 

 

 2.应用与数据分离架构：

 2015年底，团队开始做了一个图片社交项目，其功能是全部模仿Instagram，但是内容主要针对的是服装、奢侈品。用户通过手机拍摄一些奢侈品、服装相关的视频、图片，并添加对应的下载链接，发布到平台后，用户可以看到其他所有人发布的内容，并可以根据链接购买。

 这个项目中涉及到大量视频、图片的处理，这里我们实现了应用服务、数据服务、资源服务的分离。我们购买了四台阿里云服务器，分别是两台ECS、一台OSS、一台RDS，其结构如下图：

 

 

 

 
 

 

 

 
3.集群式部署初级架构

 2016年我们开始做一个大型的在线教育平台项目，经历一年的磨合，项目趋于稳定，我们的服务器架构也日臻完善。本想总结一下服务器的架构，在下笔之前在网上看到了他人总结的一篇文章
，项目架构设计总结，再此先向作者表示敬意，以下是引用的这篇文章的部分内容：

 

 
 
 --------------------------------------引用有此处开始--------------------------------------
 
 

 

 
 项目背景
  项目的前端主要为ios应用以及一些web管理系统，后端的职能主要为前端提供数据接口。我个人在项目中主要负责整个后端的架构设计、服务器运维、php开发等一系列后端工作，因为主要是我一个人负责，在一定程度上也减少了许多沟通成本。
  
  总体架构
  
  项目后端架构使用阿里云服务搭建，其中RDS为主从集群，并配备灾备实例。ECS可根据业务量动态弹性伸缩，其余服务均采用单实例的方式远程调用。
  
 
 
 
  
  VPC
  
  搭建VPC的原因有以下几点
  1.可以将业务数据库和业务服务器放置在可以自己掌握的同一内网，可以提高一些安全性。
  2.阿里云服务之间通过内网访问的流量是不收费的。所以在选购服务时，带宽可以选择流量版，这样在保证带宽速率的同时，还可以极大的减少运维费用。
  举个例子：同样一台ECS，在同为百兆带宽的情况下，每月的费用如下图：
  
  按固定带宽
 
 
 
  按使用流量
  
 
 
  当然，能这样的做的原因也是因为在这个架构中，ECS仅处理业务逻辑，几乎不存储文件资源。大部分静态资源，如视频图片等，都是存储在OSS上。如果存放静态资源，比如下视频或图片什么的，流量一多那就很亏了。
  3.内网访问，稳定而且速度快。
  
  业务数据层
  
  RDS
  项目一开始，RDS选购的是共享型单实例的，随着业务量的提升，可以多区域部署只读实例。另外，保险起见，主实例可以配有一个灾备实例，防止意外发生。
  
  Redis
  提到阿里云的这个Redis，不得不吐槽一句，它竟然是不支持主从的，只能单实例，不过，用它做数据缓存，还真是蛮不错的选择，响应速度非常快。而且，因为是放置在内网的且只能内网访问，所以安全性也很高。
  
  MongoDB
  结构型数据，主要存储档案式的数据，比如每个用户的操作行为，以档案式记录并进行统计分析，方便下一阶段的项目做个性化服务。另外一些关联复杂的数据，也可以用MongoDb存储，可以提高访问速度。还有，一些对软件应用版本比较敏感的数据也可以存在MongoDB中，比如a版本拿到A数据，b版本拿到B数据，而这个AB数据都是由很多关联关系复杂的数据所组成，如果把这些数据根据版本号存储在不同的MongoDB档案中，需要时，直接根据版本号拿就可以了，这样就避免了很多的mysql查询。
  
  静态资源
  
  OSS + CDN
  OSS存储静态资源，CDN(内容分发网络)可以加速静态资源的下载速度。至于资源链接地址，客户端可以通过接口访问从后端业务数据库中拿到。
  服务器安全
  
  运维层面
  1.选购了阿里云的web防火墙和态势感知的服务。这两个服务可以实时监控服务器状态，识别并跟踪攻击来源和类型，可以说，用这两个工具也节省了很多人力成本。阿里云还有其它安全类产品，可以根据项目选购，使用起来也都很方便。
  2.配置firewalld。
  
  业务层面
  针对接口访问的安全性，主要做了以下工作
  1.签名验证：防止伪造请求
  2.访问频次限制：计数器是用phpredis制作的毫秒级计数器
  3.https访问
  4.部分敏感数据，使用RSA非对称加密
  
  服务器集群
  
  主ECS
  通过这台ECS，可以管理其它从属的ECS，并查看状态。安装的主要工具为ansible。
  如果不需要用这台ECS来做负载均衡的话，可以配置白名单连接，只允许管理员ip才能访问。
  
  从属ECS
  这类ECS服务器只存放逻辑代码，所以当需求量增加时，只需增加此类服务器的个数即可。而且，在增加个数时，可以使用之前制作好的镜像，创建多台相同环境的ECS服务器。每台ECS的web环境为nginx1.10和php7，微服务容器环境用的docker。
  
  负载均衡
  负载均衡可以采用两种方式
  1.购买阿里云的负载均衡实例(注意要买带公网ip的)。由该负载均衡实例接收请求后，会分发到内部服务器。
  2.在某台具有外网ip的ECS上使用nginx部署负载均衡服务。
  
  个人更倾向第一种，毕竟管理起来比较方便，节省人力。
  
  使用到的第三方服务
  
  Coding
  后端的所有代码都是放在Coding上的，喜欢Coding的原因有三个。
  1.私有git仓库没有个数限制。
  2.有ios客户端且比较好用。
  3.操作界面好看。
  
  后端代码的自动部署是通过Coding的webhook实现的
  具体操作可以去看这篇博客《利用Coding的webhook自动部署项目》。
  
  实现的场景：代码的自动部署与持续集成。
  当我提交代码到开发分支上时，测试服务器上会自动更新开发分支上的代码。
  当我把开发代码合并到主分支上时，正式服务器会自动拉取master分支上的代码，可谓是方便快捷。
  jenkins 之类的工具虽然也尝试过，但是感觉部署起来很不方便，不够定制化，而且还消耗了一部分服务器资源。
  
  
  后端逻辑层架构
  
  接口
  项目起初的接口是基于phalapi框架开发，现在逐步过渡到基于laravel5.3开发。
  项目起初选择phalapi的原因
  1.phalapi框架是轻量级的接口发框架，开发起来比较便捷、快速，尤其是那个依赖注入挺好用的。
  2.phalapi框架有很多现成的扩展可以使用，不用去找，而且这些也能基本满足业务的需要。我个人还基于这个框架开发了两个扩展，一个是关于使用workman的，一个是关于使用gearman的。
  其中gearman是用来异步处理请求的，详细介绍可以看这篇博客《基于Phalapi框架的gearman扩展(异步并发)》
  根据业务量提高性能
  
  http请求的并发性能可以通过增加ECS实现，针对部分耗时较长且无须即时回调的请求，可以用gearman异步处理。
  数据库的并发连接数可以通过增加配置来提高，也可以通过创建只读实例进行读写分离，提高数据处理能力。再往后，可能需要搭建hadoop管理数据库集群，不过等用上hadoop的时候，应该已经不是项目初期了，至少数据量得是TB级的了。
  其它还可以采用优化nginx配置，优化linux内核，采用高速固态硬盘等等的手段。
  #总结评价
  这套架构基本上可以完全满足项目初期的业务需要，而且所有的云服务费用总和也非常少(相比于自建服务器机房)。随着业务量的提升，可以逐步升级配置以应对需求，还可以在短时间内临时性的提高并发处理能力。总结起来就是省钱、省时、省力气。
 
 
 
 ----------------------------------------引用到此为止--------------------------------------
 
 

 

 

 
4.集群式部署国际化架构

 

 

 随着业务的扩展，最近我们的项目需要发布到海外市场，原有的服务器架构已经不能满足市场的需求。由于之前并未接触如此大的项目，对海外市场服务器的部署非常不了解，在跟阿里云架构师沟通的基础上，我们得出两种解决方案：

 

 

 
方案一：

 阿里云有一款叫全球加速的产品，该产品不用购买和部署海外服务器，只需购买全球加速服务，阿里云接入其自建的全球骨干网络，据说可实现海外访问100ms的延时。不过此种方式，成本较高，我们选择了放弃，其结构如下图：

 

 


 
方案二：

 

 

 第二种方案就是在海外部署服务器，其结构如下图：

 

 

 


 

 在上一种架构的基础上，在所需要的点购买ECS服务器，海外节点通过香港入口访问国内的RDS和Redis。同时在海外对应的节点部署CDN，用于访问OSS服务器时的加速，海外用户访问对应节点的CDN，CDN通过香港入口访问OSS服务器，并将所访问的对象文件缓存到对应的节点，当用户下次再次访问该对象时，直接从对应的CDN节点缓存中获取，以此方式提高访问速度。