微服务架构综合实战 一文让你了解什么是微服务 使用PHP 搭建微服务框架 最全微服务架构讲解以及演示
| 后台-插件-广告管理-内容页头部广告（手机） |
本文将带你从基础的微服务架构设计、网络协议、注册中心、配置中心、网关层面 渐进式讲解其微服务。
目录
一、微服务架构设计方案
架构演进
微服务概念
拆分
三个火枪手原则
AKF原则
二、微服务注册中心和配置中心
为什么要使用服务发现与注册
为什么要使用配置中心
官方下载地址
设置环境变量
Server配置
单机配置
集群配置
命令解析
ThinkPHP接入Consul
配置信息中心
三、微服务API网关设计
为什么需要网关
API网关对比
Kong与Konga的关联
konga关键概念词
下载镜像
安装
创建网络
安装postgres，kong依赖于postgres
初始化kong数据表信息
启动kong
初始化konga数据信息
创建连接节点
实现负载
创建Upstreams
创建服务
创建路由
实现Basic Auth 与 JWT 认证
添加Basic Auth插件
添加用户信息
添加JWT 插件
添加JWT 认证信息
实现Oauth2 认证
添加Oauth2 插件
添加用户信息
获取token
API限流
API黑白名单
延伸
jwt异常
虚拟机环境 IP黑白名单失效
服务恢复
四、结合swoole、swoft微服务化搭建
网络基础
OSI七层模型与TCP/IP模型
ARP 地址解析协议
经典的TCP三次握手与四次挥手
抓包
Swoft框架介绍
协程
下载框架代码
RPC 服务
使用swoft 实现RPC 服务
前期准备工作
修改配置文件
启动RPC服务
RPC客户端实现
五、整合API与Kong网关以及consul注册中心
consul服务注册
新增注册中心相关配置
添加监听注册
创建Consul控制器
启动服务
Swoft 服务发现
新增注册新增相关配置
RPC服务发现
服务限流
熔断与降级
consul与kong网关结合
加入dns_resolver 信息
添加对应的SERVER信息
后记
一、微服务架构设计方案
架构演进
在将微服务之前 我们看看目前的架构
单体架构
按照模块划分，公用一个数据库
垂直拆分架构
按业务功能划分单独的子系统，公用一个数据库
将数据库进行分拆分离，如下图：
微服务概念
微服务 即微小的服务，较小且独立的功能
微服务最早由Martin Fowler（马丁·福勒）与James Lewis于2014年共同提出，微服务架构风格是一种使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限度的集中式管理。
拆分
拆分的颗粒度没有标准答案，只能根据经验，实际，方法论等，合理的进行拆分。
粗颗粒度拆分
项目工期短且要求是微服务的架构
细颗粒度拆分
- 服务划分过细，服务间关系复杂
- 服务数量太多，团队效率急剧下降
- 没有自动化部署支撑，无法快速交付
- 没有服务治理，微服务达到一定数量，后台管理混乱
纵向拆分和横向拆分
纵向拆分：从业务纬度进行拆分。标准是按照业务的关联程度来决定，关系比较密切的业务适合拆分为一个微服务，而功能相对比较独立的业务适合单独拆分为一个微服务。
横向拆分：从公共且独立功能纬度拆分。标准是按照是否有公共的被多个其他服务调用，且依赖的资源独立不予其他业务耦合。
划分例子
- 第一种分为商品、帖子、新闻3个服务
- 第二种分为商品、订单、帖子、回帖、新闻、评论6个服务
如何选择呢？
如果你的团队只有9个人，那么分为3个是合理的，如果有18个人。那么6个服务是合理的。
为什么呢，这就是三个火枪手原则。
三个火枪手原则
三个火枪手原则就是一个微服务由三个人负责开发。一般来说，在进行微服务架构时，根据团队规模来划分微服务数量是合理的。
而为什么是3个人？？？？
从系统规模来讲，3 个人负责开发一个系统，系统的复杂度刚好达到每个人都能全面理解整个系统，又能够进行分工的粒度；如果2个人开发一个系统，系统复杂度不够；如果4个人甚至更多人开发一个系统，系统复杂度又会无法让研发人员对系统的细节都了解很深。
从团队管理来说，3个人可以形成一个稳定的备份，即使1个人有事不在，2个人也可以支撑；如果2个人的话，少了一个人剩余的1个人压力就很大；如果是1个人就更惨了
从技术角度，3个人的技术小组能够形成有效的讨论，能快速达成一致意见；如果是2个人，可能会有意见无法统一问题；如果4个人或更多，就会出现有的成员不认真讨论，开会划水。
AKF原则
AKF 把系统扩展分为以下三个维度：
- X 轴：直接水平复制应用进程来扩展系统，将系统复制多份，即加机器得方式，大大提高系统的总体容量、解决单点问题等（A+A+A+A）
- Y 轴：将功能拆分出来扩展系统。微服务经常采用的按照业务逻辑拆分（B+C=A）
- Z 轴：基于用户信息扩展系统。 将数据做分片拆分
二、微服务注册中心和配置中心
为什么要使用服务发现与注册
微服务带来最大的好处就是把整个大项目分割成不同的服务，运行在不同服务器上，实现解耦和分布式处理。微服务虽然有很多好处，但是也会有不好的一方面。任何事物都会有两面性，在微服务里面进行运维会是一个很大的难题，如果有一天我们的服务数量非常的多，然后我们又不知道哪一个服务在什么机器上。可能会有人说这部分直接写在程序的配置里面就好了，当我们服务少的时候是可以这么做的，也允许这么做，但是在实际当中我们要尽量避免这么做，比如说我们某一个服务，地址换了，那么我们设计的相关代码就得修改重新部署；又或者说我们有一天上线一个新服务或者下线一个服务，这时候我们又得修改程序代码，这是非常不合理的做法。那么有没有什么可以解决这样的问题呢？这里就需要用到我们的服务注册和发现了。
结构对比
没有服务注册发现的结构
上图 我们可以看到在没有服务注册发现的时候一个调用者需要维护多个服务的IP和端口，这是非常不友好的做法，当我们服务进行调整的时候就有可能导致服务调用失败，还有服务器更换服务器，上下新服务，都会受到影响。将来某一个服务节点出现问题，排查对应程序对运维人员来说都是一场很大的灾难，因为不知道哪一个节点出了问题，需要每一台服务器的去排查。
有服务注册发现的结构
我们从上图可以发现，当我们有注册中心之后调用者不需要自己去维护所有服务的信息了，仅需要向注册中心请求获取服务，就可以拿到想要的服务信息。这样当我们的服务有所调整，或者上线下线服务，都要可以轻松操作，并且可以在注册中间检查到服务的健康情况，帮助运维人员快速定位到故障的服务器。
为什么要使用配置中心
不使用配置中心
使用配置中心
主流的配置中心
- Apollo是有协程开源的分布式配置中心
- Spring Cloud Config
- Consul
官方下载地址
https://developer.hashicorp.com/consul/downloads
- wget https://releases.hashicorp.com/consul/1.15.1/consul_1.15.1_linux_386.zip
- unzip consul_1.15.1_linux_386.zip
设置环境变量
如果不设置可以直接把consul执行文件移动到/usr/bin目录下
mv consul /usr/bin
注：此步骤非必要
ok, 安装成功后，我们接下来进行一些配置来启用consul
Server配置
单机配置
- 服务器1，IP 192.168.5.189
声明
1.本站遵循行业规范，任何转载的稿件都会明确标注作者和来源；2.本站的原创文章，请转载时务必注明文章作者和来源，不尊重原创的行为我们将追究责任；3.作者投稿可能会经我们编辑修改或补充。
在线投稿：投稿 站长QQ：1888636
后台-插件-广告管理-内容页尾部广告（手机）
关注我们
扫一扫关注我们，了解最新精彩内容
