微信业务架构

构图元素：分层、分区、关系

构图规则：上下支撑、左右组合，一侧开放、一侧公共机制

微信业务分析

人 + 生活场景

泛社交场景，延伸到生活、 购物、娱乐、工作，连接一切（人和人，人和物）（在不同场景产生的活动、事件）

人的属性：

1. 用户身份 （我是谁 what）、

2. 权限信息（功能权限、第三方应用授权）、

3. 位置信息（我在哪里 where）、

4. 好友关系、关注订阅陌生人关系 (我和他人的连接)

场景应用

社交需求：

1. 通讯录、私聊、群聊、语音聊天、视频聊天

2. 资讯传播、内容表达：朋友圈（熟人）、看一看（熟人+陌生人）、公众号（陌生人）、视频号（熟人+陌生人）、直播、微信读书

3. 购物生活：小商店、商城、支付、钱包、（O2O）

4. 娱乐：小游戏、视频号、直播

5. 工作：企业微信、腾讯文档、腾讯会议

支撑业务所需的基础应用服务

用户中心：用户、好友关系、订阅关注关系、用户身份认证、功能授权、第三方应用授权

身份识别：身份码（识别人）、小程序码/游戏码（识别应用）、公众号（识别内容机构）

消息中心：个人消息、群消息、订阅号消息、公众号消息、小程序消息

地理位置： 人的位置(附近的人)、事件位置（朋友圈）、附近的小程序

搜索服务：搜用户、搜公众号、搜小程序、搜文章内容应用

服务分发：小程序、小游戏、小商店

支付服务：钱包、扫码、收付款、转账、红包

开放平台：移动应用接入/网站接入、 公众号开发、小游戏开发、小商店开发、小程序开发、支付场景接入

学生管理系统

1、面向复杂度的架构设计 - 判断复杂度

高性能： 少量，1000 用户

高可用： 数据高可用, 数据不丢

可扩展： 可伸缩性

成本、安全： 要求低成本

面向复杂度的架构设计 - 设计备选方案

备选方案 1：最大化云服务方案+单一技术栈

备选方案 2：适量云服务方案+单一技术栈

备选方案 3：适量云服务+多技术栈

面向复杂度的架构设计 - 方案取舍（三原则判断：合适、简单、演进）

团队技术水平：

学习成本角度考虑，单一技术栈复杂度最低

开发效率角度，PHP 做应用效率比 JAVA 更高，方案 3 复杂度较高 ，简单原则，考虑方案 1，2

方案成本 ：

方案 2 全 ECS 方案 按天付费，短期内成本最低，硬件成本最低，维护成本上，

方案 1 全云方案，长期运维成本最低

开发周期： 团队存在 PHP 高手，PHP 开发应用效率更高，方案 3，PHP 应用+JAVA 服务 > JAVA 应用+JAVA 服务，方案 1 和方案 2 相同

毕设场景，综合考虑：推荐方案 2，学习成本最低，短期使用成本最低，架构简单