前言

虽然老师说一般架构图可以使用 PPT 画，但个人还是喜欢 processon 来画，真的比 PPT 要好使，而且里面积累了不少素材，所以这次还是用 proccesson 吧。

微信业务架构图

题目是绘制微信的业务架构图，应该是主要考察同学们对于业务粒度和覆盖度的把握，而不是对于微信业务的理解程度。以下是一些个人的理解，微信作为腾讯集团主要的流量入口，集成了了集团内部几乎所有的功能，粗看微信本身的业务并不复杂，自身主要集中到社交领域，但作为局外人其实分不太清楚，腾讯内部微信与其他应用之间的边界，比如微信支付是属于微信还是属于财付通呢。

考虑到这个题目的本质是要考察业务粒度的把握和业务架构图的基本画法，因此这里我就把明显不属于微信的应用排除，凡是可能属于微信的都画进来，这样也比较好看(doge).

实际架构图如下所示。

学生管理系统架构设计

题目

假设今年学校毕业设计要求提升，要求做真正可运行的学生管理系统，学院对毕设的具体要求如下： 1）要求可以通过公网域名访问；

2）要求至少 3 人合作完成；

3）能够支撑管理 1000 个学生；

4）答辩的时候会根据架构方案来进行打分，不推荐太简单和太复杂的方案

你找了 2 个好朋友一起来做这个项目，你们的基本情况如下：

1）大家都会 Java，但是有一个是 PHP 高手

2）大家经济条件一般

作业要求：

1）对照面向复杂度架构设计方法论，构思 2 个以上的备选架构方案。

2）使用 PPT 来画出你的备选架构方案，并说明方案的优缺点。

3）给出你选择的最终方案以及选择理由

题目分析

题目要求这里就不重复了，毕设题目是做真正可运行的学生管理系统，其中“真正可运行”这个概念还是比较模糊的，什么才算是真正可运行，是仅仅跑起来通过一系列测试就行可以还是要真正的支撑起 1000 个学生实际使用啊，经老师确认只要你能说服老师系统可以支撑管理 1000 个学生即可。还有就是多人合作，要考虑不同人员的技术栈情况，还有大家经济情况一般，所以太奢侈的方案就不要考虑了。

需要注意的事背景是完成毕业设计，所以貌似目标是做真正可运行的学生管理系统，但实际目标是高水平的完成毕业设计。所以有必要将系统架构设计的稍微高大尚一点，有针对性，这样才能在评审中获得较高的评价，大家的技术栈以 Java 为主，还有一个 PHP 高手可以搞前端。

所以这里有几个重点，第一个是架构不能太简单要有亮点和针对性，基本确定以 spring cloud 全家桶迅速搞出来，第二个是不要花太多钱，第三个是公网域名访问，第四个是 PHP 做前台。

个人答案

备选方案 A

方案思路

这个方案比较传统，通过云平台购买域名和云主机，为节省经费，以按需的方式采购。系统架构采用业界“主流”的微服务架构，服务拆分为位学生微服务，课程微服务，权限微服务，配合 nacos 作为注册和配置中心，Zuul 作为服务网关来进行服务路由，Zuul 前面还有一个 Nginx 作为负载均衡，PHP 服务作为前台提供服务，跟 Zuul 都在 nginx 下面挂着，而且根据负载情况可以部署多个 PHP 实例来提高性能。学生，课程，权限这些业务服务每个都有两个服务实例，为了节省开支，分为两组部署在云主机上，每组都有三个服务。

方案优点

采用 nginx 作为第一层负载均衡，分离前后端，使用 Zuul 作为路由服务，并且每个服务都至少部署两个实例，可以实现服务层面的负载均衡。直接使用云上的 mysql 服务，更加稳定，为了数据安全增加了数据数据库备份服务。整体设计较为简单，而且符合出微服务架构设计风格和必要组件。

方案缺点

设计除了微服务的体现外，缺乏亮点，实际需要使用 mysql 云服务和三台云服务还有域名，需要一定的费用，但采用按需付费的模式问题应该也不大。域名正式使用还需要备案实名制还是比较麻烦

备选方案 B

方案思路

总体思路跟方案 A 类似，选择微服务风格的架构设计，与方案 A 不同的地方主要有两点：

1. 将选课微服务从课程微服务中独立出来，并增加消息中间件。这主要是应对选课的高峰，避免系统高峰时候频繁崩溃。

2. 只选择一台云主机，主要是用来获得独立 IP 和绑定申请的公网域名，这样可以节省下来两台云主机和 mysql 服务的费用，只需要花费几十块钱买一个 IP 盒子就可以实现公网静态 IP

方案优点

• 费用低，付费部分只需要几十块钱的 IP 盒子和一台云主机。

• 针对性强，针对选课场景，增加独立的选课微服务和消息中间件来削峰填谷，保证系统的可用度和用户的使用体验。

方案缺点

系统的整体复杂度有所提高，而且后台服务通过 IP 盒子连接，整体延迟可能会较高。

备选方案 C

方案思路

方案 C 与方案 B 类似，但不再需要独立的云服务器，而是全部使用本地主机，公网域名访问时依靠 Sunny-Ngrok 实现的，使用这个服务可以获得一个自定义的子域名来访问指定的客户端主机，这时 Sunny-Ngrok 类似一个接入网关。

方案优点

• 节省预算，几十块钱购买一个月的 Sunny-Ngrok 服务即可，甚至可以使用免费版的。

方案缺点

• 由于 Sunny-Ngrok 对于用户并发有限制，只容许同时 60 个连接，所以系统整体的并发能力有限。

最终方案

可以跟导师商量一下能否认同方案 C，如果认同就选择方案 C，否则就选择方案 B。

如果无法跟导师商量和确认，就直接选择方案 B，以防答辩时被怼，并发无法满足要求。

学习总结

转眼间模块一已经结束了，时间还真是快啊，当初还纠结了很久要不要购买这节课。最终驱动参与的原因就是想看看一线大厂的架构师到底是如何工作的，他们是否跟我有一样的困扰。学完了第一模块，基本确认了当初的选择是正确的。

所谓架构师是本质上就是解决系统复杂度问题的，就像老师说的架构师并非在软件行业一出现就有的，而是随着软件规模出现自然而然出现的岗位。其实在其他领域也是一样，当一个系统复杂到一定程度都会出现为了解决复杂问题的岗位，比如说航天系统的总体设计师，比如说项目管理的项目经理都是一样的道理。

模块一的核心内容主要有以下几点：

• 4R 架构，Rank+Role+Relation+Rules

• 架构设计环

• 架构设计原则的意义

实际上个人感觉，架构设计无时无刻都在考虑一个折中和权衡的问题，都是一个度的问题，不一定大厂的方案就适合你，不一定主流的就适合你们团队，适合的才是好的。