PHP分布式微服务架构的手工实现 -01

微服务架构现状

近些年通信技术的提升，互联网的飞跃式发展，产生各种大流量，大并发的互联网应用场景。
以前，大家都是单体架构的系统，现在单体架构已经被淘汰，流行的是微服务分布式架构。
在微服务领域，php被java压着打，这就很蛋疼。其实微服务本身没有语言限制。
但是java在这个领域轮子多，有成体系的学习套路，比如spring cloud 微服务全家桶，dubbo 等，
学习方向很明确。反观php这块，基本上很多人半路出家，底子差，加上前几年没有啥现成的套路，基本上在微服务这块就算是落下了。

今天我将通过nginx 的配置，以及一些简单的例子来阐述一个基本的分布式微服务架构是什么样子的。
抛砖引玉，希望和大家一起探讨下，您如果在系统架构这块有什么疑问，或者想法，可以加我Q【476984957】,单独详聊。

本文只是简单示例，不涉及到具体深入的东西，为新手提供个入门参考，后续会陆续推出PHP分布式微服务系统相关的文章

建议

phper 学习分布式微服务系统架构，我个人的一些建议

1. 向java取经

目前整个国内行情来看，java微服务生态比较完备，各种轮子大把的有，抛开语言层的东西，转换下就可以成为php的微服务实现。

2. 转变思想

试着去用现成的轮子，不少做php的朋友特别爱自己造轮子，其实没必要，试着用现成的轮子去解决问题。

3. 化繁为简

不要追求复杂的架构，不要追求复杂的概念，
基本上系统一但复杂化，国内往往是往java转，复杂化会增加学习成本，更加难以理解。

4. 夯实基础

微服务的概念听着高深，实际上还是各种基础技术组合的产物。不少phper半路出家，基础上还有欠账，跟风行业风向，大家都在微服务，我也跟着微服务，结果一头扎进去之后学的一头雾水。

基础知识点

接下来我会列举 两三个知识点，不做太深入讨论，只为大家指个方向。
本次我们假设有一个系统中，有如下两个子系统：
OMS 订单管理系统 ：http://192.168.10.110/ ，
WMS 仓储管理系统：http://192.168.10.120/ ，
我们将针对这两个子系统，做反向代理配置，以及负载均衡配置

1.nginx反向代理

示例配置如下：

server {
		listen       80;
		server_name  localhost;
		
		location /wms {
			proxy_pass  http://192.168.10.110/;
			proxy_set_header Host $host;
			proxy_set_header X-Forwarded-For $remote_addr;
			proxy_set_header X-Forwarded-Host $server_name;
			proxy_set_header X-Real-IP $remote_addr;
		}
		
		location /oms {
			proxy_pass  http://192.168.10.120/;
			proxy_set_header Host $host;
			proxy_set_header X-Forwarded-For $remote_addr;
			proxy_set_header X-Forwarded-Host $server_name;
			proxy_set_header X-Real-IP $remote_addr;
		}
	}

通过示例，其实可以看到，我们通过反向代理，将系统服务做了一个拆分。这个就是微服务中的服务拆分。

2. nginx 负载均衡

负载均衡 和 微服务概念关系不大，主要用来做缓解接口并发，
例如，当oms服务的api请求单机撑不住的时候，就需要多台机器来支撑，
简单配置示例：
反向代理的配置调整后为：

http{
		upstream oms {
			server 192.168.10.110 weight=3;# oms 01 号机器
			server 192.168.10.111 weight=3;# oms 02 号机器
			server 192.168.10.112 weight=4;# oms 03 号机器
		}
		upstream wms {
			server 192.168.10.120 weight=3;# wms 01 号机器
			server 192.168.10.121 weight=3;# wms 02 号机器
			server 192.168.10.122 weight=4;# wms 03 号机器
		}
		server {
				listen       80;
				server_name  localhost;
				
				location /wms {
					proxy_pass  http://wms;
					proxy_set_header Host $host;
					proxy_set_header X-Forwarded-For $remote_addr;
					proxy_set_header X-Forwarded-Host $server_name;
					proxy_set_header X-Real-IP $remote_addr;
				}
				
				location /oms {
					proxy_pass  http://oms;
					proxy_set_header Host $host;
					proxy_set_header X-Forwarded-For $remote_addr;
					proxy_set_header X-Forwarded-Host $server_name;
					proxy_set_header X-Real-IP $remote_addr;
				}
			}
	}

通过以上配置，我们解决了API接口中并发的问题，假设你oms单机只能支持500并发，通过三台机器，那差不多就可以撑住1000多并发

总结

看了上面的内容之后，是不是觉得这些玩意儿跟微服务架构有啥关系。(^o)/~
不急，我来讲解下：
我们先看一张图，

此图基本上就是一个分布式微服务的总体架构示意图，当然，实际中会有其他的架构，但是我这里只讨论php中比较容易实现的架构，其他复杂架构不讨论，笔者个人经历中，一但到了中后期，基本都是转了java，此中原因，这里不多说，我有空了再单开一章来讲。

看图，发现此图中，重点是 这个 API网关，它起到把各个服务对外提供的 API 汇聚起来，让外界看起来是一个统一的接口，这里，我们在调用接口时，就是 http://localhost/oms/ 和 http://localhost/wms/
这样。其他的就不展开，
在php分布式微服务架构中，我们这里实际上没有引入API网关组件，而是自己手动用nginx去配置了一个有部分API网关功能的代理服务器。那么这一整个体系，实际上就是一种微服务。
我们在未引入其他组件的情况下，进行了一次手工的分布式微服务系统的架构体验。