标签：输出 debug 相关 分层 接口 mave 阻塞 后端服务 zuul
网上流传已久的 “世界上最好的语言是 php”，说实话，php 基本上什么都能做，每个领域都能找到一些库。但是在性能上确实有一定的问题。
性能上，传统有 C++ 和 Java，现代有 Go 和 Node 还有 Rust，php 虽然搭上 swoole 在这个领域也才算及格。php 天生不支持多线程并发，虽然搭上了 swoole 也搞出了类似多线程，其实底层实现使用的是 多进程的方式。
之前和同事开玩笑说，你非让一个腿瘸的人拄着拐杖跑起来，表明上确实比之前 “跑” 的快，但是他毕竟是瘸子，不可能比正常人跑的快。
php 动态类型 + 弱类型，能不添乱就不错了。线上参差不齐的开发人员开发的代码分布在各个地方，当有朝一日出现 bug 时候，没有办法 debug，也没有办法很直观的查到问题，只能无限的打印-输出，来跟踪到可能出错的地方，之后再通过更加细致的打印-输出来判定出错的原因。往往为了寻找或调试一个简单的问题就让人心灰意冷。
要从 go 的协程与 java 的线程来考量
协程是非抢占式的用户态线程，它的所有操作都是在用户态完成的。优势：
1. 可以减少线程不同态来回切换成本以及来回保留现场所消耗的资源
2. 协程本身不存在并发的问题，因为协程本身是在一个线程中运行
3. 协程更轻量，一个协程 几十 KB，一个线程大约 1MB
所以，协程特适合的场景有：多任务调度、数据流处理 以及 接口请求等场景。而索引系统会面临各种业务调度，以及数据流的处理并写入到 es，这种场景非常契合协程的使用场景。
首先说一下前提，为什么要将服务拆分成微服务体系架构，是因为我们当前的主业务线接入的越来越多，由原来的4 条扩张到现在的 22 条，每条业务对应搜索策略、排序场景都不尽相同，当然有共同的地方可以进行抽象单独提出来。
这种前提下再加上正好搜索要做一次搜索架构重构，来解决目前架构不合理的地方，主要有：
1. 逻辑混乱，没有明确的分层，一个业务线多个主方法入口，给到业务端调用方有多个接口，导致后续维护起来非常的困难，底层 es升级迁移都无法进行。
2. 代码堆叠，一直存在重复造轮子的现象，且经历过多人多版本迭代，已经没有办法或者说不太好进行抽象和封装了。
3. 格式混乱，没有统一的命名规范、注释规范等，导致想弄明白一段逻辑的具体含义，非常困难。
所以借着这个契机，统一做了一次大的重构和优化。
接下来谈谈为什么不选用原生的 spring-cloud 技术体系，主要有以下两点考量：
1. SpringCloud中，很多核心组件，都采用 Netflix全家桶，但是 Eureka,Hystrix 宣布停止运营，Zuul 又由于其阻塞式网络模型，性能比较容易出现瓶颈。这些坏消息，给广大的开源使用者，一记重拳。
否极泰来，2018 年 10 月 31 日的凌晨，这个伟大的日子里，Spring Cloud Alibaba 正式入驻了 Spring Cloud 官方孵化器，并在 Maven 中央库发布了第一个版本。
而且，spring-cloud-alibaba 相关配套组件也一应俱全，相当好用。
2. 在各个项目中通过 rpc 方式调用，而选用的方案就是 dubbo 方式，dubbo 是 alibaba 开源的，而 spring-cloud-alibaba 也是 alibaba 开源的，他们之间可以无缝结合。
标签：输出 debug 相关 分层 接口 mave 阻塞 后端服务 zuul
原文地址：https://www.cnblogs.com/liang1101/p/13202134.html
