三、harbor简介
harbor 是私有镜像仓库，用来存储和分发镜像的
docker 还有一个官方的镜像仓库 docker hub，免费用户只能简单的使用，创建一个私有镜像仓库，存储 镜像，付费用户才可以拥有更多权限，默认 docker pull 拉取镜像就是从 docker hub 上拉取，速度极慢， 不利于生产环境使用。 harbor 私有镜像仓库拉取镜像速度极快，属于内网传输，功能也很强大：
功能：
1.基于角色访问控制：用户与 Docker 镜像仓库通过“项目”进行组织管理，一个用户可以对多个镜像仓 库在同一命名空间（project）里有不同的权限。
2.镜像复制：镜像可以在多个 Registry 实例中复制（同步）。尤其适合于负载均衡，高可用，混合云和多云 的场景
3.图形化界面：用户可以通过浏览器来浏览，检索当前 Docker 镜像仓库，管理项目和命名空间。
4.部署简单：提供在线和离线两种安装工具
5.LDAP：Harbor 可以集成企业内部已有的 AD/LDAP，用于鉴权认证管理
| 主机名 | ip | 配置 | 网络 |
| harbor | 192.168.10.12 | 2核2G centos7.9 | NAT |
3.1 初始化环境
1.修改yum源 wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo yum-config-manager --add-repo http://mirrors.aliyun.com/docker-ce/linux/centos/dockerce.repo 2.配置安装 k8s 需要的 yum 源(可要可不要) cat <<EOF > /etc/yum.repos.d/kubernetes.repo [kubernetes] name=Kubernetes baseurl=https://mirrors.aliyun.com/kubernetes/yum/repos/kubernetes-el7-x86_64 enabled=1 gpgcheck=0 EOF yum clean all yum makecache fast 3.安装依赖软件包 yum -y install wget net-tools nfs-utils lrzsz gcc gcc-c++ make cmake libxml2-devel openssl-devel curl curl-devel unzip sudo ntp libaio-devel wget vim ncurses-devel autoconf automake zlib-devel python-devel epel-release openssh-server socat ipvsadm conntrack ntpdate yum-utils device-mapper-persistent-data lvm 4.配置防火墙和关闭selinux systemctl stop firewalld && systemctl disable firewalld sed -i 's/SELINUX=enforcing/SELINUX=disabled/g' /etc/selinux/config 5.时间同步并设置定时任务 ntpdate time1.aliyun.com 6.修改内核参数 cat <<EOF > /etc/sysctl.d/k8s.conf net.bridge.bridge-nf-call-ip6tables = 1 net.bridge.bridge-nf-call-iptables = 1 EOF sysctl --system 7.修改主机名 hostnamectl set-hostname harbor 8.配置hosts文件 192.168.10.10 master 192.168.10.11 node1 192.168.10.12 harbor 9.安装docker yum install docker-ce systemctl start docker && systemctl enable docker && systemctl status docker 10.配置docker镜像加速 cat > /etc/docker/daemon.json <<EOF { "registry-mirrors":["https://pft7f97f.mirror.aliyuncs.com","https://rsbud4vc.mirror.aliyuncs.com","https://registry.docker-cn.com","https://docker.mirrors.ustc.edu.cn","https://dockerhub.azk8s.cn","http://hub-mirror.c.163.com","http://qtid6917.mirror.aliyuncs.com", "https://rncxm540.mirror.aliyuncs.com"], "exec-opts":["native.cgroupdriver=systemd"], "log-driver":"json-file", "log-opts": { "max-size": "100m" }, "storage-driver":"overlay2", "storage-opts": [ "overlay2.override_kernel_check=true" ] } EOF 重启生效 systemctl daemon-reload && systemctl restart docker && systemctl status docker
其它机器如果需要上传镜像到harbor，需要加配置一条
"insecure-registries":["192.168.40.132"] #配置的是 harbor 私有镜像仓库地址 11.开启机器bridge模式 echo """ vm.swappiness = 0 net.bridge.bridge-nf-call-iptables = 1 net.ipv4.ip_forward = 1 net.bridge.bridge-nf-call-ip6tables = 1 """ > /etc/sysctl.conf sysctl -p
3.2 为harbor签发证书
1.创建证书存储目录
mkdir /data/ssl -p
cd /data/ssl
2.生成ca证书
#生成一个 3072 位的 key，也就是私钥
[root@harbor ssl]# openssl genrsa -out ca.key 3072
#生成一个数字证书 ca.pem，3650 表示证书的有效时间是 10 年，添加国家、省份、城市，其余都为空
[root@harbor ssl]# openssl req -new -x509 -days 3650 -key ca.key -out ca.pem
# 生成域名证书：
#生成一个 3072 位的 key，也就是私钥
openssl genrsa -out harbor.key 3072
#生成一个证书请求，一会签发证书时需要的，添加国家、省份、城市还有用途common name(hostname)：harbor
openssl req -new -key harbor.key -out harbor.csr
# 签发证书
[root@harbor ssl]# openssl x509 -req -in harbor.csr -CA ca.pem -CAkey ca.key -CAcreateserial -out harbor.pem -days 3650
Signature ok
# 查看证书是否有效
openssl x509 -noout -text -in harbor.pem
[root@harbor ssl]# ls
ca.key ca.pem ca.srl harbor.csr harbor.key harbor.pem
3.3 安装和配置harbor
# 1.下载harbor安装包
https://github.com/goharbor/harbor/releases
# 2.配置harbor
tar -xzvf harbor-offline-installer-v2.4.3.tgz
cd harbor
cp harbor.yaml.tmpl harbor.yaml
# 修改参数
hostname：修改为域名或IP，这里修改为证书里配置的名称：harbor
配置https:
https:
port: 443
certificate: /data/ssl/harbor.pem
private_key: /data/ssl/harbor.key
# harbor登录密码
harbor_admin_password: Harbor12345
data_volume: /usr/local/harbor/data # 存储harbor数据位置
# 3.安装docker-compose
yum install docker-compose -y
4.执行harbor安装脚本
[root@harbor harbor]# ./install.sh --with-notary
✔ ----Harbor has been installed and started successfully.----
--with-notary 启用harbor.yml中的https配置，加载证书
--with-chartmuseum 启动镜像漏洞扫描
docker ps查看启动的镜像
如果harbor安装完成后还需要修改配置：
# docker-compose down
# ./prepare
# docker-compose up –d
# 修改端口后执行./prepare vim docker-compose.yml ports: - 8088:8080 - 6443:8443
3.4 harbor图形化界面使用配置
浏览器访问,配置本地hosts：
https://harbor
admin/Harbor12345
所有基础镜像都会放在 library 里面，这是一个公开的镜像仓库
3.4.1 新建项目
3.4.2 centos命令行登录harbor
在harbor机器上修改docker镜像加速配置：
[root@harbor harbor]# cat /etc/docker/daemon.json
{
"registry-mirrors":["https://pft7f97f.mirror.aliyuncs.com","https://rsbud4vc.mirror.aliyuncs.com","https://registry.docker-cn.com","https://docker.mirrors.ustc.edu.cn","https://dockerhub.azk8s.cn","http://hub-mirror.c.163.com","http://qtid6917.mirror.aliyuncs.com", "https://rncxm540.mirror.aliyuncs.com"],
"insecure-registries":["192.168.10.12"，"harbor.com"], # 如果有域名可以使用域名
"exec-opts":["native.cgroupdriver=systemd"],
"log-driver":"json-file",
"log-opts": {
"max-size": "100m"
},
"storage-driver":"overlay2",
"storage-opts": [
"overlay2.override_kernel_check=true"
]
}
# 修改后
systemctl daemon-reload && systemctl restart docker
注意：
配置新增加了一行内容如下：
"insecure-registries":["192.168.10.12"],
上面增加的内容表示我们内网访问 harbor 的时候走的是 http，192.168.10.12 是安装 harbor机器的 ip
[root@harbor harbor]# docker login 192.168.10.12
Username: admin
Password:
WARNING! Your password will be stored unencrypted in /root/.docker/config.json.
Configure a credential helper to remove this warning. See
https://docs.docker.com/engine/reference/commandline/login/#credentials-store
Login Succeeded
# 如果有问题就检查下镜像加速器配置文件
3.4.3 harbor仓库镜像上传和下载
# 1.准备一个镜像
[root@harbor install]# docker pull tomcat
docker.io/library/tomcat:latest
[root@harbor install]# docker images | grep tomcat
tomcat latest fb5657adc892 8 months ago 680MB
# 2.在项目中标记tomcat镜像
语法：docker tag SOURCE_IMAGE[:TAG] harbor/test/REPOSITORY[:TAG]
[root@harbor install]# docker tag tomcat:latest 192.168.10.12/test/tomcat:v1
# 3.上传镜像到harbor
[root@harbor install]# docker push 192.168.10.12/test/tomcat:v1
执行上面命令就会把 192.168.10.12/test/tomcat:v1 上传到 harbor 里的 test 项目下
# 4.从harbor仓库下载镜像
[root@harbor install]# docker images | grep tomcat
tomcat latest fb5657adc892 8 months ago 680MB
192.168.10.12/test/tomcat v1 fb5657adc892 8 months ago 680MB
删除本地镜像
[root@harbor install]# docker rmi -f 192.168.10.12/test/tomcat:v1
[root@harbor install]# docker pull 192.168.10.12/test/tomcat:v1
v1: Pulling from test/tomcat
Digest: sha256:e6d65986e3b0320bebd85733be1195179dbce481201a6b3c1ed27510cfa18351
Status: Downloaded newer image for 192.168.10.12/test/tomcat:v1
192.168.10.12/test/tomcat:v1
四、微服务
4.1 什么是微服务？
微服务是用于构建应用程序的架构风格，一个大的系统可由一个或者多个微服务组成，微服务架构可将应 用拆分成多个核心功能，每个功能都被称为一项服务，可以单独构建和部署，这意味着各项服务在工作和 出现故障的时候不会相互影响。
4.2 大型电商平台的微服务功能图
总结： 微服务架构是把一个大的系统按照不同的业务单元分解成多个职责单一的小系统，并利用简单的 方法使多个小系统相互协作，组合成一个大系统，各个小的系统是独立部署的，它们之间是松耦合的。
4.3 为什么要用微服务？
（1）单体架构扩展性差、维护成本高、不可靠
在单体架构下修改代码，需要把整个代码重新编译，重新部署，这个时间周期会很长；
单体架构下的所有代码模块都耦合在一起，代码量大，维护困难，想要更新一个模块的代码，也可能会影响其他模块，不能很好的定制化代码
所有模块都用同一个数据库，存储方式比较单一。
（3）微服务中可以有 java 编写、有 Python 编写的，他们都是靠 restful 架构风格统一成一个系统的，所 以微服务本身与具体技术无关、扩展性强
4.4 微服务特性
1）灵活部署、独立扩展
传统的单体架构是以整个系统为单位进行部署，而微服务则是以每一个独立组件（例如订单服务，商品服 务）为单位进行部署
2）资源的有效隔离
每一个微服务拥有独立的数据源，假如微服务 A 想要读写微服务 B 的数据库，只能调用微服务 B 对外暴 露的接口来完成。这样有效避免了服务之间争用数据库和缓存资源所带来的问题。另外微服务各模块部署 在 k8s 中，可以进行 CPU、内存等资源的限制和隔离.
3）高度可扩展性
随着某些服务模块的不断扩展，可以跨多个服务器和基础架构进行部署，充分满足业务需求。
4）易于部署
相对于传统的单体式应用，基于微服务的应用更加模块化且小巧，且易于部署。
5）服务组件化
在微服务架构中，需要我们对服务进行组件化分解，服务是一种进程外的组件，它通过 HTTP 等通信协议进行协作，而不是像传统组件那样镶入式的方式协同工作，每一个服务都独立开发、部署、可以有效避免 一个服务的修改引起整个系统的重新部署。
6）去中心化治理
在整个微服务架构，通过采用轻量级的契约定义接口，使得我们对服务本身的具体技术平台不再那么敏感，这样整个微服务架构系统中的各个组件就能针对不同的业务特点选择不同的技术平台。
7）容错设计
在微服务架构中，快速检测出故障源并尽可能地自动恢复服务是必须被设计考虑的，通常我们都希望在每个服务中实现监控和日志记录。比如对服务状态、断路器状态、吞吐量、网络延迟等关键数据进行可视化展示。
8）技术栈不受限
在微服务架构中，可以结合项目业务及团队的特点，合理地选择技术栈。
9）局部修改容易部署
单体应用只要有修改，就得重新部署整个应用，微服务解决了这样的问题。
10）易于开发和维护
一个微服务只会关注一个特定的业务功能，所以它业务清晰，代码量较少。
4.5 什么样的项目适合使用微服务？
在复杂度比较低的项目中，单体架构就可以满足需求，而且部署效率也会比较高，在复杂度比较高的项目 中，单体架构就不能满足了，需要进行微服务化。
微服务可以按照业务功能本身的独立性来划分，如果系统提供的业务是非常底层的，如：操作系统内核、 存储系统、网络系统、数据库系统等，这类系统都偏底层，功能和功能之间有着紧密的配合关系，如果强 制拆分为较小的服务单元，会让集成工作量急剧上升，并且这种人为的切割无法带来业务上的真正的隔离，所以无法做到独立部署和运行，也就不适合做成微服务了。
那到底什么样的项目适合微服务呢？
1. 业务并发量大，项目复杂，访问流量高，为了将来更好的扩展，随时对代码更新维护，可以使用微服务
2. 代码依赖程度高，想要解耦合，交给多个开发团队维护
3. 业务初期，服务器数量少，可以使用微服务，能有效节省资源。
4. 从思想上： 对未来有清晰的认识，对技术更新要保持着一种自信，超前思维，知道这个东西在将来肯 定会发展起来。
公司可能业务规模大，项目复杂，我就想要用微服务，或者我们在未来上有更大的远见，那我也会选择用微服务
4.6 使用微服务需要考虑的问题
4.6.1统一的配置管理中心
服务拆分以后，服务的数量非常多，如果所有的配置都以配置文件的方式放在应用本地的话，非常难以管理，可以想象当有几百上千个进程中有一个配置出现了问题，是很难将它找出来的，因而需要有统一的配置中心，来管理所有的配置，进行统一的配置下发。
在微服务中，配置往往分为几类，一类是几乎不变的配置，这种配置可以直接打在容器镜像里面，第二类 是启动时就会确定的配置，这种配置往往通过环境变量，在容器启动的时候传进去，第三类就是统一的配置，需要通过配置中心进行下发，例如在大促的情况下，有些功能需要降级，哪些功能可以降级，哪些功能不能降级，都可以在配置文件中统一配置。
4.6.2 全链路监控
全链路监控工具：pinpoint、skywalking、zipkin、prometheus
1）系统和应用的监控
监控系统和服务的健康状态和性能瓶颈，当系统出现异常的时候，监控系统可以配合告警系统，及时地发 现，通知，干预，从而保障系统的顺利运行。
2）调用关系的监控
对代码调用关系进行监控
4.6.3 日志收集
业务层面、代码层面、系统层面，通过可视化UI界面进行展示
常见工具：EFK、ELK stack
4.7 常见的微服务框架
第一代微服务框架：SpringCloud
SpringCloud 为开发者提供了快速构建分布式系统的通用模型的工具（包括配置管理、服务发现注册、 熔断器、断路器、智能路由、微代理、控制总线、一次性令牌、全局锁、领导选举、分布式会话、集群状态、负载均衡、数据监控等）
第二代微服务框架：dubbo
dubbo 是一个阿里巴巴开源出来的一个分布式服务框架，致力于提供高性能和透明化的 RPC 远程服务调 用方案，以及 SOA 服务治理方案
第三代微服务框架
1）ServiceMesh(服务网格)、k8s
k8s+istio 是开源的 ServiceMesh（服务网格），ServiceMesh 翻译成中文就是服务网格
4.8 常见的微服务框架对比分析
4.8.1 框架背景对比
SpringCloud
来源于 SpringSource ，具有 Spring 社区的强大背景支持，还有 Netflix 强大的后盾与技术输出。
Netflix 作为一家成功实践微服务架构的互联网公司，在几年前就把几乎整个微服务框架开源贡献给了社 区，这些框架开源的整套微服务架构套件是 SpringCloud 的核心。
Eureka: 服务注册发现框架；
Zuul: 服务网关；
Karyon: 服务端框架；
Ribbon: 客户端框架；
Hystrix: 服务容错组件；
Archaius: 服务配置组件；
Servo: Metrics 组件；
Blitz4j: 日志组件;
Pinpoint：全链路监控组件
Dubbo
是一个分布式服务框架，是国内互联网公司开源做的比较不错的阿里开放的微服务化治理框架，致力于提供高性能和透明化的 RPC 远程服务调用方案，以及 SOA 服务治理方案。 其核心部分包含（官网）:
远程通讯: 提供对多种基于长连接的 NIO 框架抽象封装，包括多种线程模型，序列化，以及“请求-响 应”模式的信息交换方式；
集群容错: 提供基于接口方法的透明远程过程调用，包括多协议支持，以及软负载均衡，失败容错，地 址路由，动态配置等集群支持；
自动发现: 基于注册中心目录服务，使服务消费方能动态的查找服务提供方，使地址透明，使服务提供方可以平滑增加或减少机器。
Dubbo 也是采用全 Spring 配置方式，透明化接入应用，对应用没有任何 API 侵入，只需用 Spring 加载 Dubbo的配置即可，Dubbo 基于 Spring 的 Schema 扩展进行加载。当然也支持官方不推荐的 API 调用方式。
k8s、Istio
作为用于微服务服务聚合层管理的新锐项目，是 Google、IBM、Lyft（海外共享出行公司、Uber 劲 敌） 首个共同联合开源的项目，提供了统一的连接，安全，管理和监控微服务的方案.
目前是针对 Kubernetes 环境的，社区宣称在未来几个月内会为虚拟机和 Cloud Foundry 等其他环境增加支持。 Istio 将流量管理添加到微服务中，并为增值功能（如安全性，监控，路由，连接管理和策 略）创造了基础。
HTTP、gRPC 和 TCP 网络流量的自动负载均衡；
提供了丰富的路由规则，实现细粒度的网络流量行为控制；
流量加密、服务间认证，以及强身份声明；
全范围（Fleet-wide）的策略执行；
深度遥测和报告。
4.8.2 开源社区活跃度对比
开源社区情况：现如今企业在采用云计算首选开源，而选择一个开源框架，社区的活跃度将作为重要参考选项。
查看下在 Github 上的更新时间
SpringCloud ：Spring Cloud · GitHub → 所有项目均更新于『1 小时』内。
Dubbo ：Dubbo · GitHub → 核心项目最近更新于『一个月乃至数月』前。
istio：istio · GitHub → 所有项目均更新于『30 分钟』内。
可见，项目在社区活跃度上，Istio > SpringCloud > Dubbo，结合稳定性来看，对于使用 Java 开发业务较多的企业，SpringCloud 是相对更优的选择，对于更多企业来说，与语言几乎无绑定的 Istio 也是可 以好好期待一下其在社区的发展。
总结：结合项目背景、提供功能、社区更新活跃度，SpringCloud 是目前阶段发展最早的微服务框架方案，Istio 作为 Kubernetes 的优先支持来讲，也是一个值得关注的方案，而且发展潜力巨大，相信不久 的将来 90%+的 k8s 用户都会使用 istio。目前对比来看，dubbo 则显得稍逊下来。
