什么是微服务架构以及落地思路

---

前言

调用几个webapi就是微服务架构？或则是ngnix+webapi 集群就是微服务架构？这个文章带你弄懂微服务架构。

---

一、各种架构的演进

单体架构：放在一个服务器进程完成全部的后端处理，搞不定怎么办，那就搞多几台。

水平拆分：多台服务器，这时候也就是集群模式，多个服务器干一样的事情。

垂直拆分：多台服务器，处理不同的事情，写协作完成。

分布式 ：一个请求，有时候需要多个进程服务互相调用。也就是多进程协作完成一个完整流程。（业务逼的，双11活动，大并发）
好处：可以扩充处理能力，独立部署，独立升级维护
坏处：如果处理 数据一致性问题 ， 分布式锁等处理方案

二、微服务架构

微服务结构就是在分布式技术成熟后，通过分布式服务来拆分业务逻辑，完成解耦，并且通过一系列组建和方法论来解决落地问题

这套架构风格 + 落地标准 就是微服务架构

类比之前的三层架构
三层架构，UI - BLL - DAL 调用分层方法
微服务：每个服务就是方法，调用分布式服务, 推荐以DDD服务拆分而不是BLL式拆分

微服务的核心要求：
高可用，可伸缩 ： ngnix +任意节点都要集群 + 服务注册发现；调用问题–网关Gateway（服务熔断，负载均衡，路由转发，限流，超时，重试）

落地思路

ngnix 配置负载均衡

upstrem ServeName {
   server 127.0.0.1:3333
   server 127.0.0.1:6666
   server 127.0.0.1:9999
}

server {
   listent 8080
   server_name localhost
   location / {
     proxy_pass http://xxx/api/
   }
}

上述3台server启动后，通过ngnix负载均衡配置后，请求 http://localhost:8080/api/xx的时候，就会随机打到3台服务，当然可以通过配置权重等其他配置来达到特殊的需求配置；
当要频繁新增server或则减少server的时候，配置后需要手动改后，重启
ngnix reload -s
每次手动重启，效率低，浪费时间，就是浪费生命，那么怎么解决？ 还得是自动化。。。。
Consul
这时候类似 consul 服务注册发现的解决方案
服务注册
通过consul注册实例，在consul后台，可以看到注册的实例列表；由他来控制。 那当实例启动的时候在consul注册后，当实例挂了，例如断电，实例想通知consul也做不到，这时候只能由consul自己来判断实例是否正常运作，用的手段就是Health Check 也就是心跳💗检测；
服务发现：
调用的注册的实例列表，也就是服务发现。获取后是一个实例数组。可以写逻辑代码来控制访问那个实例的权重等规则；

网关Gateway
解决方案eg： Kong ，Envoy ，Spring Cloud GateWay，Ocelot
1.交叉调用
2.多独立IP
3.服务安全
4.服务治理 - 缓存

SSO 分布式环境下，SSO(single sign on) 单点登录
1.http 无状态协议
2. Cookie–session
3. 共享存储
4. 客服端携带Token
网关完成多个微服务的鉴权授权，就是 SSO。

功能性要求：
skyapm-全链路追踪-能看可视化看到请求链路，以及各种细节信息
apollo–分布式配置中心–可视化集中管理，提供回滚-通知等功能
EL-ELK-分布式日志-可视化集中管理，可搜索过滤
分布式锁
分布式事务

运维需求-DevOps：
docker 容器化
300多docker-- K8s 完成容器编排 管理
Git- jenkins – CI/CD

---

总结

微服务架构也是从简单的架构例如单体架构，为了解决各种架构在实际应用的缺点，慢慢演进。