什么是业务后台系统（合家云社区物业管理平台）

1、后台系统架构设计

外卖系统全局加购

前端后端大数据

业务前台系统	业务后台系统	数据中台
外卖IOS端	外卖商品《—- 商品数据	数据集市
Android端	外卖订单《— 订单数据	数据计算
PC端	外卖配送《—配送数据	报表分析

业务后台系统举例

例子：电商业务：查询商品信息系统，保存订单的系统

短视频和资讯类：查询视频基本信息和咨询的系统，能够保存短视频的系统

2、业务后台系统的分类

所有技术实现的都是增删改查，无法区分后台系统

基于目的性维度进行分类，并提取技术共性，总结出通用的技术架构

读业务场景写业务场景扣减业务场景

读业务场景举例：微博，知乎等咨询类业系统，其主要目的就是为了用户提供阅读和浏览信息业务

特点：读多写少，读的并发量非常大 RT响应速度

写业务场景类举例：外卖，打车等交易类的业务场景，主要目的是完成每一笔订单的写入，保证企业的收入

写业务特点：尽最大可能提高系统的可用性，权利做到极致的高可用，写入服务是无法使用缓存的，对于各大电商，鼓掌回复时间需要再一分钟以内或者秒级别。

高可用评价标准：1个9到5个9

扣减类业务场景举例：扣减库存，扣减金额，次数扣减

如果扣减失败，那么提单也无法成功

扣减业务要抗住并发保障数据的一致性

以库存为例，扣减的请求只会包含购买商品和对应数量，二具体能不能购买，则以来后台系统存储的当前剩余库存数量。另外，不同用户在同一时刻可能购买同一个上商品，此外就存在并发更新，这种在并发情况下的扣减一致性就需要格外注意。

总结：读业务场景：高可用+高性能

写业务场景：999以上高可用

扣减业务场景：保障数据的一致性

3、复杂系统的拆分之道

为什么进行拆分：

好处：1、开发直接，代码和项目集中式管理

2、排查问题是只需要排查这个应用就可以了，更有针对性

3、只需要维护一个工程，节省维护系统运行的人力成本

问题：

1、单体架构增加了研发的成本抑制了研发效率的提升

2、单体架构对于系统的运维也会有很大的影响

什么时候开始微服务：当业务复杂度达到一定程度后，微服务的成本更低

4、什么时候进行拆分

前提：业务规模、团队规模、技术储备、人才储备、研发效率

快速占领市场、百人、注册中心、配置中心、日志系统、持续之父、监控系统等技术栈，精通微服务的同学、研发效率大大下降。

如何决定微服务架构的拆分粒度：1、团队规模 50% 2、支付速度要求 30% 3、其他20%

5、如何进行拆分

1、垂直划分优先原则

可能导致问题：调用次数更多导致性能大幅下降

实现一个功能要跨越更多服务。沟通成本升高

例子：电商后台

用户商品促销购物车订单其他

2、持续演进原则

服务数量快速增长带来架构复杂度急剧升高，开发，测试，运维等环节很难快速适应，会导致故障率大幅增加，可用性降低，应该逐步划分，持续演进，避免服务数量的爆炸性增长

3、服务资质，接口隔离原则

尽量消除对其他服务的强依赖，这样可以降低沟通成本，提升服务稳定性

4、自动化驱动原则

在服务划分之前，应该寿阳县构建自动化的工具环境。

以微信读书为例

业务流程：注册，登录，浏览，购买，支付，阅读

注册和登录属于用户模块，浏览属于商品模块和促销模块，购买属于订单模块，之父属于支付模块，阅读属于阅读模块

第二次拆分：按照技术维度进行垂直拆分

合家云社区物业管理平台

项目介绍

合家云社区物业管理平台是一个全新的智慧物业解决方案“，是一款互联网+的专业社区物业管理系统。平台通过社区资产管理、小区管理、访客管理、在线报修、意见投诉等多种功能模块，来全面提升社区工作人员的工作效率和客户服务质量，主要致力于构建一个为社区居民更好服务的优质互联网平台。

需求分析

系统设计

前后端分离

前后端分离已成为互联网项目开发的业界标准使用方式，将前端和后端的开发进行解耦。并且前后端分离会为以后的大型分布式架构、微服务架构、多端化服务(各种客户端，比如浏览器、车载终端、安卓、IOS等)打下坚实的基础。
前后端分离的核心思想就是前端HTML页面通过AJAX调用后端的API接口，并通过JSON数据进行交互

前后端分离优势

1.前后端分离的模式下，如果发现Bug，可以快速定位是谁的问题，不会出现互相踢皮球的现象

2.前后端分离可以减少后端服务器的并发/负载压力。除了接口以外的其他所有HTTP请求全部转移到前端Nginx上，接口的请求则转发调用Tomcat.
3.前后端分离的模式下，即使后端服务器暂时超时或宕机了，前端页面也会正常访问，只不过数据刷不出来而
4.前后端分离会更加合理的分配团队的工作量，减轻后端团队的工作量，提高了性能和可扩展性.