一 物理架构的选型
- 根据具体的业务类型进行分析业务量
- 面向C端用户群体还是B端
- 评估服务上线平常的请求量以及峰值请求量，去申请相应配置的服务器，及相应流量的机房，哪个版本的操作系统，负载均衡的方式等等。
二 数据库架构的设计
- 分析未来的业务的增长能到达某个数据量，选择相应的数据库产品
- 当前市场流行mysql，5.7版本较于5.5版本有相当性能上的提升，以及选用哪种引擎，是否支持读写分离或者主从策略，都要预先考虑好。
- 设计的表结构，尽量遵守三大范氏设计，注意留有字段扩展。
三 软件架构
- 首先还是根据业务来做分析，不同的业务软件架构设计也相差很大
- 分析上线之后用户请求量有多大，参与项目开发人员有多少，如何进行鉴权设计，异常处理
举例:
比如铂涛旅行：app
- 客户端：vue框架+ios或者android混合开发
优势:可以快速迭代，更方便的推出一些日常营销活动，相对客户端上线审核时间长。 - 服务端：java，负责数据的个性化展示以及签名的验证
- 底层：SOA的设计，有很多个服务，例如会员基础服务，房态推送服务、预定服务、支付网关服务、收银台服务、搜索服务、储值服务、积分服务、优惠券服务。这些服务服务于几千万用户的。所以稳定性要求特别高。这样去设计也可以避免单独的某个服务down机了而影响其他服务的使用
- 具体的业务架构：项目分层MVC模式，按照具体业务分层又具体到，controller层、model数据层、view层、service层、有些为了更好的复用service层的方法会加入logic层，最后是数据持久层也就是dao层。
这样设计项目的层次会更清晰，在新的业务加入时会更加容易，整个架构会比较清晰。
有时候在设计预定方面系统我们采用责任连设计模式方便业务的解藕，定义输出的实体bean可以使用构造模式等，在设计商城系统的购物车可以使用redis存放，设计秒杀系统的时候为了防止多抢可以加入队列，以及redis的原子性操作来达到库存的一 致性等。
在项目结构设计上按照具体的模块分成一个项目比如model模块，service模块，公共模块，第三方服务调用模块，主web工程模块，通过maven可以灵活的配置工程的打包情况。
目前我司正在往docker方向前进，目前部分服务已更换成springcloud微服务。
预警监控系统：zabbix
监控服务的安全，机器的运行状态，实现自定义的预警，比如说你的房态推送失败或者订单支付失败异常单这种邮件提醒等。
分布式链路日志系统:
日志链，记录每一个请求所达到的某个服务的访问的服务、时间、等。方便定位线上问题。
设计方案：Flume（日志收集） + ElasticSearch（日志查询）+ Kibana（日志分析与展示）
Kibana搜索部分可以换成自己开发后台查询系统。
以上只是个人随想到的一些点，碎片式整理，非专业系统化整理，thks。
网友评论