大佬们，请教一个系统架构问题

没问题, 你这设计实际上还是微服务.

> 4. 两个 jar 包可能会有相互调用，方案是通过 HTTP 请求调用

你这个请求加一个管理，就跟微服务的技术栈一毛一样了
是不是“微”服务就只取决于你的 jar 包的拆分粒度了

微服务就是用来解决你这么搞，搞出来的一堆问题，包括链路监控，负载均衡，灰度发布，横向扩展，服务发现

何不直接上 spring-cloud

没问题，还是微服务

我遇到的一般都是这种架构啊，java jar 包一般是用的 zk+dubbo，go 的遇到的是用 gRpc+consul

回复一下各位大佬：
1.考虑到各方面原因暂时不直接上微服务，其实这架构是一个缩小版的微服务。
2.主要是网关、权限、登录那一块怕会有问题。

@specita 是的啊，主要是现在情况是不让用微服务的相关组件

Istio 可以了解一下, 至于权限, 登录. 你已经走微服务架构了, 这两块也可以独立一个 jar 包, 并不一定要写在网关里, 只不过你的 verify 可以在网关层面做拦截. 怕有坑不去踩你成长不了. 这对你以后架构设计也有经验帮助.

跟我们情况很像，最开始 cloud 都搭建完毕，网关什么的我都写好了，突然不让用注册中心（说是直接 30W 买两台 F5 比维护这么多机器更方便。。。），直接通过 keepalived+vip+ nginx，而且还是两台机器搞这一坨，虚拟两个 ip，一个内网一个公网，也没啥毛病，反正咱也说不上话

微服务太耗硬件资源，有些 B 端应用这么做没啥毛病

还有个问题，网关那一块在这种架构下有没有什么比较好的解决方案呢？目前设计的网关这块主要作用是登录，权限认证那些

>>> 4. 两个 jar 互相调用

这一点还是慎重一点吧。任其发展下去，又是一团乱麻。

不用担心微服务的复杂度，最简单的微服务可以没有注册中心，没有配置中心，没有网关，没有限流 /熔断，不用任何微服务组件，只是把你的一个服务拆分成多个。
当然，增加一个 Eureka 提供服务的注册 /发现，然后服务间调用就可以很方便地使用 FeignClient 了。好吧，搞个 Gateway 服务做网关，实现输入输出日志审计和鉴权什么的也挺香的，而且也不费事。配置中心可以用现成的，譬如携程的 Apollo，不用也没关系，我们就没用。
至于熔断器什么的，大多数系统根本用不上，你就先不要考虑了。慢慢来吧，基本的微服务架构真的很简单。

部门描述：～～～～～～～

代码平台（代码托管、代码效能、代码智能）是阿里巴巴一站式智能研发协同平台的核心服务，对内为阿里几万产品研发相关人员提供工具支撑，对外是阿里云开发者生态关键一环。“Work Like Alibaba”将成为中国及至全世界开发者最潮流的口号。

本职位主要职责是负责代码平台基础设施的架构演进、Git 核心技术开发，代码领域技术趋势跟踪、下一代代码平台预言。我们是一群懂代码，爱 Git，有技术有梦想的工程师。让我们一起携手解决跨地域、分布式、海量代码托管等世界级业务和技术难题，为阿里巴巴集团内部、生态伙伴以及云上开发者服务。


我们的使命：帮助企业让更多的工作内容和工作行为 “有意义” 的数字化。
我们的愿景：服务一亿人的数字化办公。


岗位描述：
1、代码平台后端大规模服务器集群的分布式架构演进；
2、服务器计算、存储资源的再平衡、故障修复与隔离，服务器智能运维；
3、基于分布式存储的下一代代码平台，实现低延迟、高效率在线编码；
4、Git 核心代码开发，业界趋势跟踪，保持技术领先，优化用户体验等等。


岗位要求：～～
1、3 到 8 年的工作经验，精通 Go 语言、C 语言或 java 语言的一种。
2、熟悉分布式一致性协议，有分布式系统开发经验。
3、熟悉微服务架构，RPC 的基本原理、gRPC、pb 等原理和使用，加分。
4、热爱技术，有较强的学习能力、良好的团队合作能力、抗压能力。

其实 soa 和微服务有个毛区别，都是瞎造概念，搞出个中心化的 api 网关和原来的 esb 本质都是一个东西，也就是 service mesh 结合服务容器化有点新东西