项目开发之系统架构

一、开发流程

1.需求、设计评审

1.1 项目需求评审

 需求清单、交付特性、设计需求、项目计划

1.2 设计评审：研究项目技术细节

 产品设计规格、Story设计文档、概要设计/详细设计

1.3 开发阶段评审

 开发自测（自我评审代码、UT）、代码评审

1.4 测试阶段评审

 功能是否实现、主流程是否畅通不阻塞测试、转测试质量评估；
 测试策略、测试用例，后期主要是开展SIT、SVT

1.5 上线评审点

 上线质量评估、用户验证测试、资料的评审。

参考链接

2.系统架构设计

1.1 系统架构设计说明书

1.2 系统架构演进

（1）单库单应用

（2）内容分发：

 解决静态资源（网页，图片，js,css等）的访问性能问题。
OSS云存储（阿里云，七牛云等）和一个CDN加速网络.

（3）查询分离模式：

 解决查询性能问题。
 概念：数据库的主从分离，并引入了ES搜索引擎；
 读写比例：7；3（甚至8：2）以上；
 解决方案举例：先尝试读从库，如果读不到就再尝试读主库。

（4）分库分表模式：

 解决单表写入压力过大的问题。

（5）微服务架构模式

 可行的拆分指导原则是：能不分就不分，除非有非常必要的理由。

（6）弹性伸缩模式：

 解决流量高并发（流量突发）的问题。
 作用：用来动态的增加、减少实例。
 成熟的两种资源池方案：VM、docker，每个产品目前都有着自己强大的生态。
 监控的点：CPU、内存、硬盘、网络IO、服务质量等。
 如何实现：根据以上，在配合一些预留、扩张、收缩策略，就可以简单的实现自动伸缩。

3.架构与框架区别

1.1 举例

 例如：一个星期完成系统架构设计— 采用MVC架构 ，再用两个星期开发好系统框架—采用springmvc框架，三个星期软件开发完成。

1.2 软件架构

（1） 名词：哪些组件构成、软件之间如何交互的抽象视图、指导整个产品生命周期的不同活动，不同阶段面向不同的受众。

 包括概念架构视图、逻辑架构视图、物理架构视图

（2）动词：架构设计，产生上述视图的决策过程。

 如：纵向如何分层、横向如何划分模块、采用什么技术路线等。
架构有常见的套路 ：
– 架构模式：分层模式、主从模式、代理模式、管道-过滤器模式、事件总线模式
—**领域、场景分：**C/S架构、B/S架构、分布式架构、SOA架构、微服务架构

1.3 框架：

（1） 特殊的半成品软件、程序骨架

 软件架构中描述的基础组件、通用组件、组件通信规则、约束的代码化，并给出了信息流或业务代码模板。
 开发人员在此基础上开发相应的业务程序，又快又好的开发程序产品。

（2）第三方框架：

 举例：常说使用了某某框架 — 某一方向的通用解决方案，包含一系列的类库和工具。
 web前端框架：vue
 后端：ssm、boot、cloud，
 数据层ORM：bibernate、mybatis

3.产品、技术架构

下面围绕业务系统进行分析

1.1 业务类系统分类

 业务类系统（通常称为To B 类产品）：一般包括crm、供应链、物流等
 用户的To C 类前台产品：产品经理非常懂业务，考验PM能力的同时，对技术架构有一定了解

1.2 技术架构的三个要素：功能、系统、架构

 三要素的顺序一定是从功能到系统，最后是架构

（1）功能元素指的是一系列的操作集合，能构成一个完整的功能，

 比如：登录、注册。技术上可以叫做模块，产品上称为功能。

（2）系统是指相互之间有直接或间接关系的功能元素形成的集合，此集合能单独为特定使用者提供特定的服务

 比如：销售系统、客服系统。

（3）我们说的技术架构， 一定是“多个”独立系统之间的事情。

 技术架构就是指把不同的功能元素（系统）放在适宜的环节、合适的层级，并且建立功能与功能，系统与系统之间关系，形成一个结构化、平台化、体验简约的大系统。
 各层次之间虽然相关，但同一层级的功能系统之间一定是独立的，同时客观上也常常对应着不同的技术部门和业务部门。

1.3 产品与技术架构的两个原则：

（1） 技术架构和产品架构，必须一致，各自用不同逻辑做拆分，建关系，那是灾难。

（2）业务导向：产品即是服务

1.4 用户系统、业务系统：

（1） 用户系统：

 以产品为中心，设计理念是我有什么能提供给用户；

（2）业务系统：

 以客户为中心，理念是你需要什么。企业级的用户系统。面向运营，面向商家以客户为中心。

1.5 运营驱动

（1） 概念

什么是好的产品（业务模式）？？：应该就是解决用户真实需求的实际痛点。从痛处入手。这里的用户可以是Toc的消费者，也可以是面向公司运营单位。
合理的公司架构：是运营驱动。
运营：就是人为的干预规则，规则就是咱们的产品逻辑，也就是业务规则。
备注：无论是做产品还是技术，掌握业务结果非常极其特别十分的重要，但大部分产品和技术都对此不感兴趣，也就限制了个人的上升空间

（2） 掌握业务执行结果

电信和互联网时代的到来， 我们可以清楚的掌握业务执行结果，也就是用户使用我们的系统到底做了什么。通过使用者的使用情况，从结果知道客户需要什么，更新规则。
这套逻辑在业务系统提现得更加清楚明确， 用规则去约束销售、客户，接单后的动作，规定动作的时间等。
通过了解使用者对规则的执行情况，对比团队以及公司的KPI，分析偏差了那些，为什么偏差，再次升级系统，干预规则，干预偏差。
运营驱动，适合多个运营单位合作，非业务驱动的产品模式。很多时候，业务流程和公司组织架构的实际情况，做不到或者不需要运营驱动

（3）业务结果

（1）系统运行状况：前者及格线是系统出了问题你要第一时间知道，不能等运营单位投诉再排查。
（2）使用结果：就是每天到底多少用户，多少订单成立率转化率，这些必须关心。不能光想着系统怎么去实现，更要知道业务用你的系统做出了什么，以及每次升级为什么而做。

6.数据运营：
6. 1 三阶段作用：发生了什么（报表），为什么发生（数据分析）和将要发生什么（决策支持）。
例如：大多数互联网公司其实还没解决业务发生了什么，包括很多上市公司，每天到底多少线索，多少订单，各种转化率，真的没谱。国内也就BAT（京东，滴滴，美团不够了解）的主营业务算是数据过关。
6.2 人员
决策人员：决策者、高层管理者，通常只是用送到手中的极简单工具，极少自己分析；
分析人员：业务管理者、专业分析人员利用商务智能各种工具向决策者制作数据内容并解释数据含义；
一线人员：一线业务人员，利用工具向管理者固定汇报业务状态、进行少量分析。

7.什么是CRM–客户关系管理
7.1 意义：CRM的意义是实现收入可预期的最大化
7.2 重点:提升人效
人效概念：人效，就是人均卖多少商品或人均贡献多少收入，是考核团队首要的KPI。 这里的人包括销售、运营、客服、产品和技术等。
7.3
路径： 提升人效的路径，就是让机器承担更多的工作，即“服务数字化”
标准化：标准化是数字化的基础，计算机只能保存离散的数据，所以标准化的核心是离散化的信息结构化。比如：建单、工单、分配等。
自动化：自动化指的是动态过程的数字化，比如流程、规则、权限控制的数字化。“动态”意味着各种存在依赖关系的元素互相之间的状态关系。
智能化：直观的理解就是让系统具备思考能力，这意味着系统在比较确定的上下文中具备分析能力。

根据项目开发进度和任务分配，开发相应的软件模块，根据需要及时修改和完善项目软件；

参考链接

——————————————————————————————

随心所往，看见未来。Follow your heart，see light！

欢迎点赞、关注、收藏，转发及留言，一起学习、交流！