温故而知新，可以为师矣
第一部分：项目架构演变过程
架构分类
1.单体架构
单体架构所有模块和功能都集中在一个项目中 ，部署时也是将项目所有功能部整体署到服务器中。
优点
- 小项目开发快 成本低
- 架构简单
- 易于测试
- 易于部署
缺点
- 大项目模块耦合严重 不易开发 维护 沟通成本高
- 新增业务困难
- 核心业务与边缘业务混合在一块，出现问题互相影响
2.垂直架构
根据业务把项目垂直切割成多个项目，因此这种架构称之为垂直架构。 为了避免上面提到的那些问题，我们开始做模块的垂直划分，做垂直划分的原则是基于业务特性，核心目标，第一个是为了业务之间互不影响，第二个是在研发团队的壮大后为了提高效率，减少之 间的依赖。
优点
- 系统拆分实现了流量分担，解决了并发问题
- 可以针对不同系统进行优化
- 方便水平扩展，负载均衡，容错率提高
- 系统间相互独立，互不影响，新的业务迭代时更加高效
缺点
- 服务系统之间接口调用硬编码
- 搭建集群之后，实现负载均衡比较复杂
- 服务系统接口调用监控不到位 调用方式不统一
- 服务监控不到位
- 数据库资源浪费，充斥慢查询，主从同步延迟大
3.分布式架构（SOA）
SOA 全称为 Service Oriented Architecture ，即面向服务的架构 。它是在垂直划分的基础上 ,将每个项目 拆分出多个具备松耦合的服务 ,一个服务通常以独立的形式存在于操作系统进程中。各个服务之间通过网络调用，这使得构建在各种各样的系统中的服务可以以一种统一和通用的方式进行交互。
解释说明:
分层: 按照业务性质分层 每一层要求简单 和 容易维护
- 应用层: 距离用户最近的一层 也称之为接入层 使用tomcat 作为web容器 接收用户请求 使用下游的dubbo提供的接口来返回数据 并且该层禁止访问数据库
- 业务服务层:根据具体的业务场景 演变而来的模块 比如 简历投递 职位搜索 职位推荐等
- 基础业务层:拉勾网招聘业务的核心 账号 简历 公司 职位
- 基础服务层:这一层 是与业务无关的模块 是一些通用的服务，这类服务的特点:请求量大 逻辑简单 特性明显 功能独立 如：消息服务（发邮件 短信 微信）附件解析 50% 自己上传附件简历 需要解析成pdf
- 存储层:不同的存储类型 Mysql Mongodb ES fastDFS
分级:按照业务性质分层 同一层的业务也要做好分级 依据业务的重要性进行分级 按照二八定律，网站80%的流量 都在核心功能上面 要优先保证核心业务的稳定。
隔离:不同性质 不同重要性的业务做好隔离 包括 业务 缓存 DB 中间件 都要做好隔离 比如 核心业务的数据库 要和活动相关的数据库隔离
调用 :总体上调用要单向 可以跨层调用 但不能出现逆向调用
优点
- 服务以接口为粒度，为开发者屏蔽远程调用底层细节 使用Dubbo 面向接口远程方法调用屏蔽了底层调用细节
- 业务分层以后架构更加清晰 并且每个业务模块职责单一 扩展性更强
- 数据隔离，权限回收，数据访问都通过接口 让系统更加稳定 安全服务应用本身无状态化 这里的无状态化指的是应用本身不做内存级缓存 而是把数据存入 db
- 服务责任易确定 每个服务可以确定责任人 这样更容易保证服务质量和稳定
缺点
- 粒度控制复杂 如果没有控制好服务的粒度 服务的模块就会越来越多 就会引发 超时 分布式事务等问题
- 服务接口数量不宜控制 容易引发接口爆炸 所以服务接口建议以业务场景进行单位划分 并对相近的业务做抽象 防止接口爆炸
- 版本升级兼容困难 尽量不要删除方法 字段 枚举类型的新增字段也可能不兼容
- 调用链路长 服务质量不可监控 调用链路变长 下游抖动可能会影响到上游业务 最终形成连锁反应 服务质量不稳定 同时链路的变成使得服务质量的监控变得困难
4.微服务架构
微服务架构是一种将单个应用程序 作为一套小型服务开发的方法，每种应用程序都在其自己的进程中独立运行，并使用轻量级机制 ( 通常是 HTTP 资源的API)进行通信。这些服务是围绕业务功能构建的，可以通过全自动部署机制进行独立部署。这些服务的集中化管理非常少，它们可以用不同的编程语言编写，并使用不同的数据存储技术。
微服务是在 SOA 上做的升华 , 粒度更加细致，微服务架构强调的一个重点是 “业务需要彻底的组件化和服务化 ” 。
