spring cloud Alibaba 微服务拆分与编写学习笔记二

一、单体应用

1、定义：一个归档包（例如war包）包含所有功能的应用程序，通常为单体应用。而架构单体的方法论，就是单体应用架构。

2、优缺点：

（1）优：

• 架构简单
• 开发、测试、部署方便

（2）缺：

• 复杂性高：项目大，模块边界模糊、代码质量参差不齐、人员质量参差不齐，随着功能不断变化，项目越做越混乱，最后导致项目越来越复杂，加简单功能，修改bug都会带来许多问题
• 部署慢、部署频率低：全量部署，每次影响范围大，上线风险高
• 扩展能力受限
• 阻碍技术创新：换框架难，尝试新技术风险高

二、微服务

1、定义：把复杂系统拆分成若干个小型应用，小型应用通过协作共同构建一个系统，每个小型应用就是所谓的微服务。

2、特性：
（1）每个微服务可以运行在自己的进程里（意味着每个微服务都有自己的tomcat）
（2）一系列独立运行的微服务共同构建整个系统
（3）每个微服务为独立的业务开发，一个微服务只关注某个特定的功能，例如订单管理、用户管理等
（4）可以使用不同的语言和数据存储技术（契合项目情况和团队实力）
（5）微服务之间通过轻量的通信机制进行通信（通信协议轻量、允许跨平台），例如REST API 进行调用
（6）全自动的部署机制：微服务的基石，微服务并不是一个开发框架，是一个完整的架构方法论，此方法论前提就是能自动化东西尽量自动化，如构建、部署、测试

3、优缺点：
（1）优：

• 单个服务更易于开发、维护
• 单个微服务启动较快
• 局部修改部署容易
• 技术栈不受限
• 按需伸缩：若某个服务比较耗CPU，只需将此服务迁移到CPU性能强的服务器

（2）缺：

• 运维要求高（需求全自动部署机制）
• 分布式固有的复杂性（微服务本职就是分布式应用，如网络延迟、分布式事务）
• 重复劳动：如A服务有stringUtil，B服务也需要stringUtil,且两个服务采用不同语言，就需要重复劳动，就开发两遍

4、应用场景：
（1）适合场景：大型、复杂的项目（能用单体架构搞定，无需使用微服务）；有快速迭代需求；访问压力大（去中心化，每个服务都有各自数据库，吞吐率高）
（2）不适合场景：业务稳定；迭代周期长

三 微服务拆分

1、业界流行的方法论：领域驱动设计（domain driver design，ddd）、面向对象（状态 by name、行为 by verb 思考问题）
2、个人心得：职责划分、通用性划分（用户中心、消息中心）
3、合理粒度：良好满足业务；幸福感，团队没人认为微服务太大、难维护、部署高效；增量迭代，微服务相对独立；持续进化，更换技术选型方便
4、小程序拆分（实际情况更适合使用单体应用，在此仅为演示使用）
（1）使用面向对象，将小程序拆分为用户中心、内容中心；用户中心是按照通用性划分；内容中心是根据职责划分，关心与内容相关的业务

四 数据库设计

1、数据建模

PS：建模工具mysql workbench，支持将模型导出sql语句，进行快速创建

2、把表建好

五 小程序创建

请移步到GitHub到老师的开源项目

六 创建项目

1、技术选型

（1）spring boot（快速开发）
（2）spring MVC（MVC框架爱）
（3）mybatis （持久层框架，操作数据库）+ 通用mapper
（4）spring cloud Alibaba（分布式）

2、工程结构规划图

3、用户中心、内容中心 SpringBoot应用快速搭建

（1）使用spring initializr快速创建SpringBoot应用
（2）加依赖：

• 通用mapper，4.0后，无需添加mappers参数（之前此参数十分重要），需要加上@MapperScan或者在所有接口增加@Mapper
  

（3）加配置

（4）专用代码生成器配置并使用（还有通用代码生成器，上手难，暂不使用，感兴趣自行研究，GitHub mapper代码生成器）

• maven插件配置
  

<plugin>
    <groupId>org.mybatis.generator</groupId>
    <artifactId>mybatis-generator-maven-plugin</artifactId>
    <version>1.3.6</version>
    <configuration>
        <configurationFile>
            ${basedir}/src/main/resources/generator/generatorConfig.xml
        </configurationFile>
        <overwrite>true</overwrite>
        <verbose>true</verbose>
    </configuration>
    <dependencies>
        <dependency>
            <groupId>mysql</groupId>
            <artifactId>mysql-connector-java</artifactId>
            <version>8.0.16</version>
        </dependency>
        <dependency>
            <groupId>tk.mybatis</groupId>
            <artifactId>mapper</artifactId>
            <version>4.1.5</version>
        </dependency>
    </dependencies>
</plugin>

• generatorConfig.xml文件配置
  ① 修改resource路径，并在同层级文件夹创建config.properties文件，并添加配置
  ② 实体类、xml、dao接口文件自动生成配置，并在config.properties加入需要生成的模块名及表名
  
  
  ③ 执行生成文件，刷新，并点击生成工具
  
  PS：实体类字段异常，需更改config.properties配置
  

（5）lombok使用，简化代码编写，提升开发效率

<dependency>
    <groupId>org.projectlombok</groupId>
    <artifactId>lombok</artifactId>
    <version>1.18.8</version>
    <scope>provided</scope>
</dependency>

• @Builder 建造者模式
  
• 代码生成器使用lombok，在generatorConfi.xml中配置

<plugin type="tk.mybatis.mapper.generator.MapperPlugin">
    <property name="mappers" value="tk.mybatis.mapper.common.Mapper"/>
    <property name="caseSensitive" value="true"/>
    <property name="lombok" value="Getter,Setter,ToString"/>
</plugin>

七 IDEA红色警告解决

老师完成的笔记总结

1、@Autowired 红色警告：默认情况要求依赖对象必须存在。而idea认为这个对象实例/代理是null，所以给了友好提示。解决方法：

• 设置requestd = false，注解不再去校验userMapper是否存在，因此不产生警告
• 用@Resource替代@Autowired 两者区别：
  ① @Resource是Java自己的注解，@Resource有两个属性是比较重要的，分是name和type；Spring将@Resource注解的name属性解析为bean的名字，而type属性则解析为bean的类型。所以如果使用name属性，则使用byName的自动注入策略，而使用type属性时则使用byType自动注入策略。如果既不指定name也不指定type属性，这时将通过反射机制使用byName自动注入策略。
  ② @Autowired是spring的注解，是spring2.5版本引入的，Autowired只根据type进行注入，不会去匹配name。如果涉及到type无法辨别注入对象时，那需要依赖@Qualifier或@Primary注解一起来修饰。
• 在Mapper文件加入@Repository或@Component（以上两个注解与@Service、@Controller之间的区别、联系）
• Lombok，@RequiredArgsConstructor(onConstructor = @__(@Autowired))

八 编写用户微服务和内容微服务

1、开发分享详情查看页面：该页面涉及内容中心share表，同时也涉及用户中心的user表，适合微服务场景


PS：在实际开发中，对于核心业务，一定要设计好开发流程，分析业务过程中，除了业务流程图，还可能用到活动图、用例图等，便于理解，且易于与同事沟通，需重视建模，没有建模的微服务是没有灵魂的

PS:RestTemplate，spring Web轻量级HTTP Client，用于简化HTTP调用