天机学堂项目微服务架构实战

1.学习背景
各位同学大家好，经过前面的学习我们已经掌握了《微服务架构》的核心技术栈。相信大家也体会到了微服务架构相对于项目一的单体架构要复杂很多，你的脑袋里也会有很多的问号：

• 微服务架构该如何拆分？
• 到了公司中我需要自己搭建微服务项目吗？
• 如果公司已经有了一个复杂的微服务项目，我该如何快速上手？
• 我该从哪里拉取代码？
• 开发的规范有哪些？
• 微服务开发的环境与传统项目有什么差异？
• …
  别担心，通过项目二的学习，上述问题你都能找到答案。
  在大多数情况下，我们进入公司接手的都是一个成熟的，或者说开发中的微服务项目。所以如何快速熟悉项目、熟悉业务流程、融入开发团队就成了我们的必修课。
  因此，项目二模拟的正是这样的开发场景：你刚刚进入了一家公司，进入了一个微服务项目组，参与一个微服务项目开发。我们会带着大家拉取代码、搭建开发环境、熟悉项目代码、熟悉业务流程、修改项目BUG、开发新功能、完成项目优化。通过整个项目的学习，真正掌握微服务架构技术栈，有能力解决微服务架构的各种问题。

2.天机学堂介绍
天机学堂是一个基于微服务架构的生产级在线教育项目，核心用户不是K12群体，而是面向成年人的非学历职业技能培训平台。相比之前的项目课程，其业务完整度、真实度、复杂度都非常的高，与企业真实项目非常接近。
通过天机学堂项目，你能学习到在线教育中核心的学习辅助系统、考试系统，电商类项目的促销优惠系统等等。更能学习到微服务开发中的各种热点问题，以及不同场景对应的解决方案。学完以后你会收获很多的“哇塞”。
2.1.行业背景
2021年7月，国务院颁布《关于进一步减轻义务教育阶段学生作业负担和校外培训负担的意见》，简称“双减”政策。在该政策影响下，多年来占据我国教育培训行业半壁江山的课外辅导培训遭到毁灭性打击。相对的，职业教育培训的市场规模持续增长：

项目学习地址 www.cx1314.cn

3.1.企业开发模式
在企业开发中，微服务项目非常庞大，往往有十几个，甚至数十个，数百个微服务。而这些微服务也会交给不同的开发组去完成开发。你可能只参与其中的某几个微服务开发，那么问题来了：
如果我的微服务需要访问其它微服务怎么办？
难道说我需要把所有的微服务都部署到自己的电脑吗？

很明显，这样做是不现实的。第一，不是所有的代码你都有访问的权限；第二，你的电脑可能无法运行这数十、数百的微服务。

因此，企业往往会提供一个通用的公共开发、测试环境，在其中部署很多公共服务，以及其它团队开发好的、开发中的微服务。
而我们大多数情况下只在本地运行正在开发的微服务，此时我们就需要一些其它的测试手段：

• 单元测试：测试最小的可测试单元
• 集成测试：验证某些功能接口，是否能与其它微服务正确交互
• 组件测试：验证微服务组件
• 端对端联调：验证整个系统

单元测试
单元测试一般是在项目的test目录下自己编写的测试，可以针对具体到每一个方法的测试。

集成测试
接口开发完成后，可能需要调用其它微服务接口，此时可以调用开发环境中的其它微服务，测试接口功能是否正常工作。

组件测试
将自己团队开发的微服务部署到开发环境，作为一个微服务组件，与开发环境中的其它微服务联调，测试整个微服务是否正常工作。

端对端测试
在测试环境部署前端、后端微服务群，直接进行前后端的联调测试。

当然，实际中我们可以把集成测试与组件测试合并，开发完成后直接与开发环境的其它微服务联调，测试服务工作状态。
[图片]

在天机学堂中，我们也给大家模拟了这样的一个开发环境，其中部署了各种公共服务，而我们只需要在本地开发未完成的几个服务即可：
[图片]

3.2.导入虚拟机
为了模拟企业中的开发环境，我们利用虚拟机搭建了一套开发环境，其中部署了开发常用的组件：

• Git私服（gogs）：代码全部提交带了自己的Git私服，模拟企业开发的代码管理，大家也需要自行到私服拉取代码
• jenkins：持续集成，目前已经添加了所有部署脚本和Git钩子，代码推送会自动编译，可以根据需求手动部署
• nacos：服务注册中心、统一配置管理，大多数共享的配置都已经交给nacos处理
• seata：分布式事务管理
• xxl-job：分布式任务系统
• es：索引库
• redis：缓存库
• mysql：数据库
• kibana：es控制台
  如图：
  [图片]

导入方式有两种：

• 方式一：下载完整虚拟机并导入，参考文档《虚拟机导入说明》
• 方式二：下载基础DockerCompose文件，及基础数据，利用脚本一键部署。参考文档《自定义部署》

注意：导入虚拟机后所有软件即可使用，无需重复安装，VMware一定要按照文档中设置IP，不要私自修改。一定要关闭windows防火墙。

3.3.配置本机hosts
为了模拟使用域名访问，我们需要在本地配置hosts：
192.168.150.101 git.tianji.com
192.168.150.101 jenkins.tianji.com
192.168.150.101 mq.tianji.com
192.168.150.101 nacos.tianji.com
192.168.150.101 xxljob.tianji.com
192.168.150.101 es.tianji.com
192.168.150.101 api.tianji.com
192.168.150.101 www.tianji.com
192.168.150.101 manage.tianji.com
192.168.150.101 cpolar.tianji.com
当我们访问上述域名时，请求实际是发送到了虚拟机，而虚拟机中的Nginx会对这些域名做反向代理，这样我们就能请求到对应的组件了：
[图片]

在浏览器中输入对应域名，即可查看到对应服务，例如Git私服地址：http://git.tianji.com
[图片]
每个域名对应的服务列表如下：
名称
域名
账号
端口
Git私服
git.tianji.com
tjxt/123321
10880
Jenkins持续集成
jenkins.tianji.com
root/123
18080
RabbitMQ
mq.tianji.com
tjxt/123321
15672
Nacos控制台
nacos.tianji.com
nacos/nacos
8848
xxl-job控制台
xxljob.tianji.com
admin/123456
8880
ES的Kibana控制台
es.tianji.com

5601
微服务网关
api.tianji.com

10010
用户端入口
www.tianji.com

18081
管理端入口
manage.tianji.com

18082

同样，我们访问用户端或者管理端页面时，也会被Nginx反向代理：
[图片]
当我们访问www.tianji.com时，请求会被代理到虚拟机中的 /usr/local/src/tj-portal目录中的静态资源
当页面访问api.tianji.com时，请求会被代理到虚拟机中的网关服务。

3.4.部署
微服务部署比较麻烦，所以企业中都会采用持续集成的方式，快捷实现开发、部署一条龙服务。
为了模拟真实环境，我们在虚拟机中已经提供了一套持续集成的开发环境，代码一旦自测完成，push到Git私服后即可自动编译部署。
[图片]
而开发我们负责的微服务时，则需要在本地启动运行部分微服务。
3.3.1.虚拟机部署
项目已经基于Jenkins实现了持续集成，每当我们push代码时，就会触发项目完成自动编译和打包。
我们可以在Git仓库模拟代码push操作：

• 首先，访问http://git.tianji.com（tjxt/123321），找到tianji这个仓库，点击仓库设置按钮：
  [图片]
• 然后，点击《管理Web钩子》菜单，进入页面后点击钩子后面的修改按钮：
  [图片]
  进入页面后，向下滚动，点击测试推送按钮：
  [图片]
  然后回到jenkins页面，会发现已经触发了tjxt-dev-build的自动编译：

需要运行某个微服务时，我们只需要经过两步：

• 第一步，访问jenkins控制台：http://jenkins.tianji.com (账号：root/123)
• 第二步，点击对应微服务后面的运行按钮