我认为系统综合实践应该是教一些我们在日后工作或者开发中需要用到的技术。由于在大学的本科生课程中很少有机会学到和开发以及以后工作有关的课程，因此希望这门课可以在比较轻松的氛围下，让我们学习到一些开发或是工作中会用到的技术。

二、了解微服务

1.微服务是什么？

微服务其实就是一种思想，这个思想是：考虑如何把一个复杂的项目拆分成一个个独立的小项目。就好比是电脑中的进程，拆分成一个个小的线程一样。
而微服务架构是种架构模式，它提倡将单应程序划分成组的服务，服务之间互相协调、互相配合，为户提供最终价值。每个服务运在其独的进程中，采轻量级的通信机制互相协作。

2.微服务特点

• 解耦合
• 团队规模小
• 按天、周进行发布升级
• CI,CD的全自动化
• 自动弹性伸缩的可拓展性
• 升级、扩容不中断业务

3.微服务的优缺点

优点

• 提升开发交流，每个服务足够内聚，足够小，代码容易理解；
• 服务独立测试、部署、升级、发布；按需定制的DFX，资源利用率，每个服务可以各自进行x扩展和z扩展，而且，每个服务可以根据自己的需要部署到合适的硬件服务器上；
• 每个服务按需要选择HA的模式，选择接受服务的实例个数；容易扩大开发团队，可以针对每个服务（service）组件开发团队；
• 提高容错性（fault isolation），一个服务的内存泄露并不会让整个系统瘫痪；
• 新技术的应用，系统不会被长期限制在某个技术栈上；

缺点

• 没有银弹，微服务提高了系统的复杂度；
• 开发人员要处理分布式系统的复杂性；
• 服务之间的分布式通信问题；
• 服务的注册与发现问题；
• 服务之间的分布式事务问题；
• 数据隔离再来的报表处理问题；
• 服务之间的分布式一致性问题；
• 服务管理的复杂性，服务的编排；
• 不同服务实例的管理。

4.微服务部署

我们要进行微服务改造前，架构师要提前做好规划。
前期阶段，大致要做好如下事情：
1.和多方充分沟通，确保能符合客户和组织的需求，并且得到认同
2.和团队沟通，让队友（开发/测试/运维）理解，并且积极投入
3.和业务部门沟通，指定版本计划和上线时间
设计阶段，单微服务必须要满足以下的条件，才符合微服务的基本要求：
1.标准的 REST 风格接口（基于 HTTP 和 JSON 格式）
2.独立部署，避免共享数据库（避免因为数据库而影响整个分布式系统）
3.业务上的高内聚，减少依赖（从设计上要避免服务过大或者太小）
庞大的分布式系统，需要强大基础设施来支撑，微服务要涉及的基础设施：
1.CI/CD和自动化（分布式系统几乎不可能通过人工手动发布）
2.虚拟化技术（要保证微服务运行环境隔离，目前行业主流的是使用 Docker 容器）
3.日志聚合，全链路监控（高度可观察和分析诊断问题）

三、学习docker技术

在ubuntu系统上安装docker

下载

安装

添加 Docker 的官方 GPG 密钥：

验证是否拥有带有指纹的密钥

设置稳定版仓库

安装最新版本 Docker Engine-Community

验证是否安装成功

容器运用

开启容器

首先需要先输入docker pull httpd拉取httpd镜像
或者直接输入docker run -it httpd /bin/bash，如果没有该镜像，会自动拉取

退出容器

退出容器只需要在容器中输入exit，即可退出

查看容器

重启容器

输入docker restart <容器ID>即可重启容器

后台运行容器

输入docker restart <容器ID>即可重启容器

进入后台运行的容器

输入docker attach <容器ID>即可进入后台运行的容器

删除容器

输入docker rm -f <容器ID>即可删除容器

用容器输出hello world

仓库管理

这里用到的是docker官方的docker hub仓库，因此需要先去官方网站注册账号

创建仓库

登录账号

输入docker login，并输入用户名和密码即可登录

查看本地镜像

输入docker image,即可查看本地的镜像

拉镜像到本地

此处我原本是没有httpd镜像的，然后我输入docker pull httpd，再次查看本地镜像，可以看到我的镜像多了httpd镜像

Push镜像

按以下格式输入代码即可push镜像至仓库

docker  tag  <镜像id> <要推入仓库的用户名>/<要推入的仓库名>:<新定义的tag> 
docker push <要推入仓库的用户名>/<要推入的仓库名>:<镜像标签>

可以在docker hub官网上看到，我的镜像被push进了仓库