学习总结报告 21天转型微服务实战营

《21天转型微服务实战营》 学习总结报告

一句话，本次学习我主要有以下收获：

• 观念上：
  • 技术上不是问题，意识比工具重要
  • 适当的模块化，有助于提高效率，便于维护
• 理论上：
  • 首先要理解，到底什么是微服务？
  • 微服务的优势
  • 华为微服务的特点（本文不着重此问题，理念、技术比工具更重要）
• 实践上：
  • 对我开发软件有什么启发？
  • 关于当今软件工程发展趋势的思考

说明：
本文力求清晰明了，以更加明确的总结自己的收获，同时做到与实践结合
我结合了我的以下项目的开发经历

• 1 心理预约平台 ： 官方平台！已在云上协同上线
  • 单点登录的微服务
• 2 Besti校园圈 ： 1500+用户
  • 对API请求模块进行封装，提高模块化程度
  • 通过模块化爬虫模块，多点部署，利用微服务的思想，实现负载均衡
• 3 Besti图书馆 ： 600+用户
  • 反面案例，应该将按钮模块提前封装，方便统一管理所有按钮
• 4 网空系党团学信息管理系统 ： 暂未上线
  • 对API请求模块进行封装，统一API请求格式，快捷地实现更安全的身份认证

1 什么是微服务

虽然这看起来是个简单的问题，但华为视频中介绍的不是很清楚，所以我想：学好本节课最重要的其实就是要真正理解什么是“微服务”。

1.0 官方的定义

官方定义很抽象，非常难懂，只有自己真正去研究，去实践，才能体会到其中的奥秘。

1、一些列的独立的服务共同组成系统
2、单独部署，跑在自己的进程中
3、每个服务为独立的业务开发
4、分布式管理
5、非常强调隔离性

1.1 我的理解

这种新概念貌似是一个需要意会，很难言传的东西，可谓是：“一解释就懂，一问就不知，一讨论就打架”，我在学习的过程中，参考了许多架构设计，结合了自己以往“传统的设计方案”，最终得到了以下理解。

首先要知道， 微服务是相对什么而言的，我认为就是相对单体式应用而言的。

就是：把一个大型的应用程序，拆分为数个甚至数十个的支持微服务。

一句话，就是更加顶层的API设计

按照功能分类拆分，从而将功能分解到离散的各个服务当中，从而降低系统的耦合性，并提供更加灵活的服务支持。

目的是：用一些功能比较明确、业务比较精练的服务去解决更大、更实际的问题。

1.2 结合我的开发经历

想要理解这个概念，必须结合实际

1.2.1 对比中总结

想要理解好：“微服务”，就不得不结合实际，因为只有做到：

对比了“传统服务架构”，才可能真正理解什么是微服务。

对此，我参考了我之前开发的Besti校园圈，他采用的传统的开发架构（既有BS，又有CS）。

校园圈开发中（包括我之前所有的开发），都是一下子就把整个系统完成了，在开发的过程中，也有对模块的划分，对各个抽象类的设计。极大提高了我的编写效率，通过分类组织每个模块每个功能，我自己一个人在较短的时间内，完成了这个大型软件的开发。

功能结构图如下所示：

但，，，这不是微服务，因为微服务，强调的是“把每个大模块的功能进行切分”

最直观的感悟就是：

微服务要求：按照业务，而不是技术来划分组织

1.2.2 具体例子

1.2.2.1 Besti校园圈

Besti校园圈是我开发我一款“一站式”校园应用，教务、图书馆、体温上报、云上协同（云校）等功能。
目前校内用户量：1500+

校园圈的业务逻辑非常简单易懂，但因为功能多，所以在开发过程中，遇到的最大问题就是：“不便于后期维护”。

举个例子：

校园圈中API（主要指前后端调用的HTTP请求API ）的调用非常乱，以至于我最后难以生成一个统一的API文档。

学习了微服务之后，我认为，我可以：
①将前端最底层的HTTP请求发送模块进行封装，将数据格式整理成统一的格式。
②对后端接受HTTP请求的模块进行封装，统一按照一种规范去处理发过来的HTTP请求。

一句话
将数据传输模块设计成一个微服务
这样的优点是简单，所有服务对于前台调用方透明

1.2.2.2 Besti图书馆

Besti图书馆是我开发的一款类似校园图书馆的第三方预约工具，PC端，采用了CS架构。
目前校内用户量：600+

Besti图书馆相对于校园圈，最大的特点就是代码比较混乱，尤其是顶层设计的时候，代码非常不清晰。

最主要的原因是：该软件使用了qt开发，而且他的按钮太多，导致非常乱，各种传参非常麻烦，在编写代码时也遇到了许多困难。

学了微架构以后，我想到，可以采用一种全新的方案：
通过重新编写按钮类（pushbutton），方便各个模块间数据的调用（设计一套数据调用的总体规范，从而让整个程序更加清晰）

1.2.2.3 学校官方的心理预约系统

云上协同（云校）中的心理预约系统也由我独自开发，目前已经上线使用，每周为同学们提供预约服务。

1.3 小结

经过实践分析，我认识到：
虽然网课中一直在讲解华为的微服务架构，但是，一定不能忘了：谁是本，谁是末！

一句话，
一般提到微服务都离不开DevOps和Docker，理解微服务架构是核心，devops和docker仅仅是工具，是手段。

2 微服务有哪些优势

微服务的优势必须相较“传统服务”而言，因此必须结合实际。

2.1 我的体会

我最大的感悟是：
微服务可以类比课堂中提到的模块化设计
从而实现：复杂度可控，独立按需扩展，技术选型灵活，容错，可用性高。

其实，微服务对我的思考，更多的是思维上的转变，而并非技术上我突破，也就是说，微服务对我最大的影响是：思想上的启迪。

对于微服务架构：技术上不是问题，意识比工具重要。

2.2 优势与思考

本章节结合了Besti校园圈的实际开发经历。

2.2.1 技术选型灵活

经常有同学问我这样的问题：一个软件能不能用多种语言来开发，比如，深度学习用Python，服务器后端用Java，数据分析用C++，组成一个完整的系统？

我的回答往往是不能。

但经过本课程学习，我有了全新的认识。

微服务是不是可以实现不同语言间的沟通呢！

只需要定义好API接口，解决好数据传参的核心问题，使用微服务架构足以达到多种语言共存的目的。这在之前是难以想象的。

2.2.2 方便升级与维护

这个很好理解，因为各个服务之间是相对独立的，所以在接口不变的前提下，内部逻辑可以自行升级。

Besti校园圈开发过程中，很好的运用到了这一点，虽然这是一个单体应用，但我开发了多个前端，比如H5网页端、Android端、微信小程序、WeLink（We码）小程序等等。

H5端：Besti校园圈链接地址

他们之间使用了同一个后端，因此，对于前后端的交互来说，接口设计尤为重要。微服务架构就可以很好的解决这个问题，通过模块化的设计，实现各个接口间高度的统一。

2.2.3 高效开发

微服务架构已将传统单体架构中的各个功能大模块拆分为了独立的服务，其中的每一个服务都是一个独立的应用，可以访问自己的数据库，这些服务对外提供公共的API，并且服务之间可以相互调用。

这听起来很玄幻，比如Besti校园圈应该很难进行拆分，因为他们每一个功能都是高度统一的。但这确实有利于超大规模的软件设计，尤其是对于系列软件设计，极大提高模块化水平，提高代码复用率，从而实现高效开发。

2.2.4 方便运维和代码维护

这个也很好理解，由于是模块化的，微服务将不同功能进行了拆分设计，所以在运维和后期中，也可是分别进行。

比如，Besti校园圈后期就尝试使用nginx进行数据分流，实现服务器的负载均衡。

2.2.5 复杂度可控

微服务架构在将应用分解的同时，规避了原本复杂度无止境的积累。每一个微服务专注于单一功能，并通过定义良好的接口清晰地表述服务边界。由于体积小、复杂度低，每个微服务可由一个小规模开发团队完全掌控，易于保持高可维护性，并提高了开发效率。

3 实践一：Besti校园圈的负载均衡

注意：这也许不是严格意义上的微服务，但确实是体现了微服务的思想理念，同时也用到了华为网课中提到：“负载均衡”

• 在微服务架构中，一般每一个服务都是有多个拷贝，来做负载均衡。一个服务随时可能下线，也可能应对临时访问压力增加新的服务节点。

• 学了本节课以后，我用双手实践了微服务了理念，将Besti校园圈的后端进行了小范围重构，主要是想解决用户量过多导致服务拥堵的问题，在后端设计中，其中，体现了一定的微服务架构的思想。

3.1 拟解决的问题

校园圈目前用户量较多，校内用户有1546人，因为我使用的服务器性能非常差（经费问题），所以后端代码编写要求比较高。当用户量提高后，Besti校园圈明显遇到了许多问题。

问题：
如何在服务器硬件资源有限的条件下，最大限度的提高服务器吞吐量，从而提高用户体验？

关键点
如何实现各个服务器设备间的负载均衡？

3.2 硬件设备

硬件设备：

• 树莓派zero
• 一台腾讯云轻量应用服务器
• 一台腾讯云弹性服务器
  
  
  

3.3 解决思路

解决思路：
根据微服务的思想，将课程表数据采集模块（爬虫）写成一个微服务，并通过nginx统一处理用户请求，进行分流转发给多台服务器处理。

• 首先，将课程表数据采集模块，拆分出来，设计成一个单独的模块
• 然后，将此模块部署到多台服务器中
• 配置nginx，进行转发，模式设置成“轮询”模式
• 即可实现负载均衡。

4 实践二：党团学系统的API网关

考虑到微服务架构中服务的数量很多，为了便于服务对外统一的管理，API网关的引入是必不可少的。API网关旨在提供统一的API入口点，来管理多个服务内部API，可方便实现对平台众多服务接口进行管控，如对访问服务的身份认证、业务鉴权、流量并发控制、API调用的计量或计费等。

本案例以“专业实习”中，我们小组开发的网空系党团学系统设计为例。

4.1 拟解决的问题

在API接口被调用时，进行鉴权，实现全平台的统一安全认证

4.2 解决思路

总体上，通过重新封装HTTP请求模块，实现统一的身份认证，同时做到前后端统一。

通过微服务的思想，使得认证模块对程序员不可见，完全隐藏，让程序更方便书写的同时，保证了安全。

设计一套加密算法，方案如下：

• 通过对学号、时间的加密，生成会话临时秘钥。
  • 加密规则不在此处公开，尽管我们使用了公开的安全算法，但保险起见，还是不写具体规则了
  • 普通key是32位，管理员key是40位
• 登录时，如果登录成功，后端生成一个token临时会话秘钥给前端
• 前端在请求所有数据时，都需要携带此秘钥
  • 注意，此秘钥不携带在数据表单中，放在请求头里，新增token字段

请求效果图如下图所示：

5 实践三：云上协同单点登录接口对接

在思政部老师和网信处的支持下，我完成了学校官方的心理预约平台建设工作。
在此期间，我有幸接触到了云上协同的单点登录模块，这个模块在一定程度上体现了微服务的思想。

5.1 浪潮单点登录接口介绍

云上协同的单点登录是微服务思想的一个体现！（按照我自己对微服务的理解，将登录模块单独拿出来，变成了一个相对独立的子功能，并提供给其他服务，可以算成一个微服务的运用）
下图是浪潮公司设计的云上协同的单点登录流程，可以看到，登录模块被完整的分割出来，作为一个单独的子系统为各个应用系统提供服务。

5.1.1 总体框架

目前，最新版的云校也采用的此认证流程。

5.1.2 认证流程

依次完成以下请求。

考虑到此文件未公开，详细细节将不在此处列出

接口	描述	方法类型
http(s): //{ip}/oauth2.0/authorize	获取authCode	GET
http(s): //{ip}/oauth2.0/token	获取accessToken	POST
http(s): //{ip}/oauth2.0/user-info	通过access_token参数获取用户信息	GET

5.2 我的实践

在网信处老师的帮助下，我终于成功使用了他们的单点登录认证模块。

目前，心理预约平台已经成功在云上协同、云校、Besti校园圈中同步上线。

6 总结

• 不知道自己理解的是否准确，我感觉微服务就是一种更加顶层的API设计，每个服务提供一个模块边界，服务上下文。独立的设计也使得每个服务能够独立更换、独立升级，而不影响其它服务。甚至能够通过自动化方式弹性扩展伸缩。

• 我之前设计软件大都采用了“单体软件设计”。单体式应用的需求的一个小改变会导致整个系统重新构建重新部署，难以让变化只影响在一个模块内，进行扩展伸缩时也只能整个系统扩展，而不能针对其一部分扩展其资源能力。

• 模块化是当今时代非常重要的开发理念，在为学校开发心理预约平台的过程中，我深刻体会到了这一点。

• 实践出真知，通过联系实际，我体会到了微服务的优势，也体会到了他的不足（比如对于一个产品来说，不是很有必要采用这种架构）

• 强化意识观念。微服务不仅为软件开发提供了一种新的开发模式（比如华为就提供了全套的技术路线支持），但我们更应该意识到，微服务给我们最大的启迪是设计思路。微服务更加强调模块化，在实际的开发过程中， 我也深切体会到了模块化设计的优势，适当的模块化能极大提高程序的可读性、复用性，从而提高大型工程的编写效率。