互联酒旅项目总结

1.组织架构

hotel-parent
├── config -- 配置中心存储配置
├── docunment -- 项目文件
├── project-admin -- 后台管理系统服务
├── project-auth -- 基于Spring Security Oauth2的统一的认证中心
├── project-common -- 工具类及通用代码块
├── project-gateway -- 基于Spring Cloud Gateway的微服务API网关服务
├── project-job -- 分布式调度系统
├── project-mbg -- MyBatisGenerator 生成的数据库 *** 作代码模块
├── project-monitor -- 基于spring Boot Admin 的微服务监控中心
├──	project-portal -- 前台门户系统服务
└── project-search -- 基于Elasticsearch的商品搜索系统服务

2.架构图流程梳理 

具体的流程大概可以跟以下：

1.用户在客户端发起请求，进行DNS(Domain Name System域名服务器)解析，其中包括WAF(Web Application Firewall)、CDN(Content Distribution Network内容分发网络)、防火墙，
2.再通过Nginx集群反向代理到Spring5.0之后添加的Webflux网关，通过SpringCloud Gateway进行动态路由指定Predicate(断言)和Filter(过滤器)寻址与Sentinel+Shard进行认证授权和令牌限流，中间还可以整合Redis；
3.另一方面还可以同时与Nacos合作为它提供监控报警和日志，集成服务注册发现功能，Nacos集群在整个架构中都能提供服务注册发现与动态配置和配置管理功能，整合SpringBoot Admin进行服务监控
4.同时Gateway可以通过Ribbon进行负载均衡、Sentinel熔断降级和业务集群建立桥梁，形成联系，先是通过SpringSecurity框架与OAuth2认证中心整合JWT进行公钥私钥的颁发授权与相应验签认证功能。
5.SpringBoot应用在业务集群中通过OpenFeign进行相互调用，中间还整合Redis、Mysql、MQ、ES、OSS、JOB等工具，其中Redis集群可以用来做分布式数据缓存，Mysql主从复制进行数据的持久化，RabbitMQ进行系统解耦削峰填谷异步调用，ES全文搜索引擎整合Kibana、Logstash进行近乎实时搜索、分析和可视化的全文检索，使用阿里云OSS云存储服务进行对象存储、企业数据管理，使用xxl-job进行分布式任务调度。
6.业务集群还与分布式相挂钩，有着分布式主键，分布式锁，分布式事务，其中有两个理论，一个是CAP(分别是Consistency一致性、Availability可用性、Partitiontolerance 分区容错性)理论(这三个要素最多只能同时实现两点，不可能三者兼顾)，一个是BASE(Basically Available基本可用、Soft State软状态、Eventual Consistency最终一致性)理论(即使无法做到强一致性，CAP的核心就是强一致性，但应用可以采用适合的方式达到最终一致性)
7.日志收集通过Beats、ELK、和Kafka整和完成，具体过程是这样的：Beats用于日志数据采集使用，Logstash收集日志，发送给Kafka进行解耦、异步处理和流量削峰，然后通过Elasticsearch集群存储日志数据，索引日志数据，再通过Kibana视图形式展现日志信息，更加人性化地在客户端进行检索以及相关 *** 作。
8.以Skywalking为核心的运维监控中心可用提供链路追踪和监控报警机制，与运维报警系统Prometheus结合Grafana最终和Alertmanager通过短信、微信或者邮件的形式给模块负责人发送警告通知。
9.最后Developer将代码文件上传到GitHub上通过docker容器部署，使用K8s AP对资源进行编排，管理应用的全生命周期，同时也提高发布与更新版本的效率，然后通过Jenkins Pipeline进行整个构建、测试、交付等持续集成，运维人员继续对这些进行维护。

3.数据库设计

 

        使用的工具是CHINER元数建模，有兴趣的同学可以使用，相对来说上手简单，规定字段的默认值和默认类别都可以较方便快捷的实现。

        上述的数据表也是经过多次改良优化得出的版本。

4.接口设计

接口设计的实现借助了工具APIPOST，对中国人的习惯确实更加友好。具体的api设计文档的链接如下：

hotel-room整合

 

 在设计API接口时的一部分注意事项：
        1.请求的方式一般使用GET/POST

        2.请求路径接口文档为准，与代码对应controller层一致

        3.GET 请求的参数在 Query 里面填写，POST 在 Body 里写。不要混用

        4.不要使用 RESTFul 的路径传参

        5.参数名采用驼峰命名

        6.数据库中存在的字段的参数，命名要保持一致，参数描述简单

        7.如果参数中用多个 id 参数，必须区分命名，且要与数据库一致

        8.响应数据示例的格式必须依据实际的格式

        9.响应数据的类型和描述和请求参数的要求一致

5.总体的开发需求

        由于第一阶段与第二阶段的代码实现主要区别是代码的优化，在基于mybatisplus开发上，更多的利用了本身分装的方法，使代码更加简洁。基础的房间号的增删改查就不再赘述。

需要注意的是：

        1.全文不要写两表或多表联查，尽量单独的用独立的service封装，联查时调用多个service即可，然后用java的流来拼起来，因为单表走索引好保证，很难保证联合查询走索引，所以不见得联查会有多快，系统拆分的话联合索引很难判断。
        2.返回值使用 CommomResult 分页 CommomResult， 返回码 使用 resultCode

        3.配置 redisTemlate 解决 redis 乱码问题

        4.log、mpaop 切面 ：log 包提供 各个 controller 的切面处理,主要是记录请求信息。mpaop 提供 在portal 和 admin添加切入点，主要记录一些集合使用的时候出现异常的记录。

        5.调用Asserts.fail 会抛出 ApiException异常，被 GlobalExceptionHandler 全局异常处理器（处理GlobalExceptionHandler 里面对应的异常），@NotNull 注解也会抛出异常被 ControllerAdvice 捕获

        6.redisServiceImpl 对 redisTemlate 的方法进一步封装。提供redis 的各项基本 *** 作。

        7.service 里面调用方法要加 this 来调用，直接继承IService。

        8.DAO,VO注意大写。

6.总结

           在师哥这一个多月的指导和安排下，从需分析和设计，数据库设计，接口设计，再到代码编写和实现，我们一步一步的学习进步，慢慢的从陌生到熟悉，团队的合作，终于完成的这个项目。在这个过程中我们遇见了很多的问题，从师哥每天的会议中都得到了解决。在项目的整个过程中，师哥是最辛苦的，每天都要指导我们，感谢师哥，感谢团队中的每位小伙伴！