2.2.业务架构设计前期工作

上节课我们演示了天宝商城系統
接下来我们从0到100实现这个商城

在真正进行架构设计前，前期需都要做哪些准备呢?

1.了解企业战略

营销战略

当你入职一家新的企业,如何快速抓住业务核心？为什么要了解核心？
以sass商城为例，就是通过收取用户下单手续费用，来获取收益，那么他
最核心的业务就是订单和支付了，这也是最重要的模块。既然是核心服务，
通常由老板最信任、技术能力更强的同事来负责。知道这些之后，
对理解整个商城业务都是非常有帮助的，其他业务需求存在的目的，都是为了
更多用户在平台下单，增长公司收益。举个例子，新推出的优惠券功能，
用户可以使用优惠券进行价格扣减下单，
进而刺激更多用户在平台下单；推出的 商家平台 模式，商家可以不需要仓库就能开商城，
更多的商家入驻，更多用户下单，收取的下单手续费用也更多。
你抓住了业务核心，如果有机会选择负责服务模块，当然选核心模块了

2.项目建设方法

微服务都已经流行了很多年了，最近要开发一个新项目，要不要用微服务？
公司的老项目是一个单体项目，太low了，要不要把他改成微服务？太纠结了，
有没有什么评判标准？
我认为并没有标准。不管是用单体架构还是微服务架构，都有他的优缺点。
只有在合适的场景下，他的缺点会缩小，优点放大，进而是最合适的选择。
我们来看这张图，对比下个自的优缺点-

如果是一个从0开始起步的项目，商业模式还在探索阶段，后台开发也才
1.2个人，那么用单体架构，因为业务开始，需求没那么多，业务也没那么复杂，
主要精力在业务开发上，快速上线。如果是一个从0开始起步的项目，需求也很明确，
后台需要5个人，才能跟上每周一迭代的任务要求，那么就要用微服务了。
这样就可以并行开发了，每个人负责自己的模块，已经非常熟悉模块了，下次加需求
也很快。换个角度，如果使用单体，A同学一下负责订单、一下负责商城，都要熟悉这些业务，
而且是在别人写的代码基础上做修改，耗时长，开发风险也大。
总之，要不要使用微服务，
看任务开发需 不要多人并行进行，且团队有人能把握住微服务
我们这个商城项目，后台开发4人，3个月上线，所以采用微服务架构

3.确定需求范围

业务需求明确
当我们要进行任务时，通常都是有时间限制的。现在要在三个月内上线
商城项目，后台有3个开发。进行任务时，有未知风险，如某同学请假，肯定影响项目
进度；中间遇到特别棘手的难题，花费大量时间去解决；中间有同学去处理bug了，也会
影响项目进度。如何保障顺利完成？通过两个方面来保障。第一，明确需求范围，
不能晕乎乎的什么都要做，并将需求重要程度做一个排序，优先开发优先级高的需求。整个项目时间的安排是前紧后松，就是说提前一段时间完成开发任务，留时间处理未知风险。第二，提前梳理出棘手的、必须要解决的难题，这样开发初期，就可以入手解决，时间也充裕，这样，整个项目进度都能把控的住。

非功能需求
什么是非功能需求？
下面表格展示了非功能需求都有哪些及不同日活下的最低要求

有性能、可靠性、安全性、易用性、可维护性、可扩展、可观察性、可伸缩。
对于不同的日活。最需求有最低的要求

对于性能要求,在日活10w以上，就需项目上线前估算出性能指标，然后进行性能测试，
性能优化了。对于可靠性需求，日活越高，高可用指标也越高，指标越高，架构设计和
代码编写的复杂度也越高。当然，如果是服务于B端业务，可靠性要求也高。
对于安全性，安全性也是一个领域问题，做到何种程度需要去平衡收益与代价。

参考上面表格，我们这个商城的非功能需求如下

满足可伸缩性、可扩展性、可维护性、易用性。
性能需求:日活 500w，QPS 达到 3000
核心接口响应时间小于 200 毫秒，普通接口小于 500 毫秒，部分特殊接口以小于 1 秒
可靠性需求：达到 99.99%
安全性:这个课程里只满足最低安全性要求
可观察性：日志平台、性能监控、服务监控

天宝商城后台系统地址:http://9c4749f024.goho.co/#/
天宝商城app下载地址:https://pan.baidu.com/s/1aCOA60NWoncfaVUO-A-Ikw?pwd=p3ew 
课程大纲:https://zcnwu4jar213.feishu.cn/wiki/IIfEwdkxwi9ENNkGhLTc8qbnnqe