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

2019-12-19 09:07:38 +08:00
 Geekerstar

有这么一个初步设想的系统架构:

1.没有采用微服务 2.后台由若干个独立的 jar 包组成(其实是一个项目按照业务拆分为多个 jar 包),每个 jar 包独立开发,使用 SpringBoot+Mybatis,但是各个 jar 包内部的技术可能不统一。 3.前台有一个网关,起到鉴权和路由的作用,网关底层由 shiro+jwt 封装实现。并在网关层面做用户登录。 4.两个 jar 包可能会有相互调用,方案是通过 HTTP 请求调用。 5.权限控制到页面(菜单)级别,控制哪些角色能看哪些页面。

请问各位大佬这样的架构有什么样的问题呢?

4934 次点击
所在节点    Java
16 条回复
Ianchen
2019-12-19 09:11:22 +08:00
没问题, 你这设计实际上还是微服务.
uleh
2019-12-19 09:17:14 +08:00
> 4. 两个 jar 包可能会有相互调用,方案是通过 HTTP 请求调用

你这个请求加一个管理,就跟微服务的技术栈一毛一样了
是不是“微”服务就只取决于你的 jar 包的拆分粒度了
lhx2008
2019-12-19 09:17:38 +08:00
微服务就是用来解决你这么搞,搞出来的一堆问题,包括链路监控,负载均衡,灰度发布,横向扩展,服务发现
securityCoding
2019-12-19 09:18:18 +08:00
何不直接上 spring-cloud
fanjianhang
2019-12-19 09:22:38 +08:00
没问题,还是微服务
specita
2019-12-19 09:27:02 +08:00
我遇到的一般都是这种架构啊,java jar 包一般是用的 zk+dubbo,go 的遇到的是用 gRpc+consul
Geekerstar
2019-12-19 09:28:08 +08:00
回复一下各位大佬:
1.考虑到各方面原因暂时不直接上微服务,其实这架构是一个缩小版的微服务。
2.主要是网关、权限、登录那一块怕会有问题。
Geekerstar
2019-12-19 09:28:53 +08:00
@specita 是的啊,主要是现在情况是不让用微服务的相关组件
Ianchen
2019-12-19 09:42:04 +08:00
Istio 可以了解一下, 至于权限, 登录. 你已经走微服务架构了, 这两块也可以独立一个 jar 包, 并不一定要写在网关里, 只不过你的 verify 可以在网关层面做拦截. 怕有坑不去踩你成长不了. 这对你以后架构设计也有经验帮助.
gosansam
2019-12-19 09:43:19 +08:00
跟我们情况很像,最开始 cloud 都搭建完毕,网关什么的我都写好了,突然不让用注册中心(说是直接 30W 买两台 F5 比维护这么多机器更方便。。。),直接通过 keepalived+vip+ nginx,而且还是两台机器搞这一坨,虚拟两个 ip,一个内网一个公网,也没啥毛病,反正咱也说不上话
dxpy
2019-12-19 09:56:44 +08:00
微服务太耗硬件资源,有些 B 端应用这么做没啥毛病
Geekerstar
2019-12-19 09:58:11 +08:00
还有个问题,网关那一块在这种架构下有没有什么比较好的解决方案呢?目前设计的网关这块主要作用是登录,权限认证那些
Xbluer
2019-12-19 10:09:39 +08:00
>>> 4. 两个 jar 互相调用

这一点还是慎重一点吧。任其发展下去,又是一团乱麻。
xuanbg
2019-12-19 13:02:10 +08:00
不用担心微服务的复杂度,最简单的微服务可以没有注册中心,没有配置中心,没有网关,没有限流 /熔断,不用任何微服务组件,只是把你的一个服务拆分成多个。
当然,增加一个 Eureka 提供服务的注册 /发现,然后服务间调用就可以很方便地使用 FeignClient 了。好吧,搞个 Gateway 服务做网关,实现输入输出日志审计和鉴权什么的也挺香的,而且也不费事。配置中心可以用现成的,譬如携程的 Apollo,不用也没关系,我们就没用。
至于熔断器什么的,大多数系统根本用不上,你就先不要考虑了。慢慢来吧,基本的微服务架构真的很简单。
dyrone
2019-12-19 13:09:28 +08:00
部门描述:~~~~~~~

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

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


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


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


岗位要求:~~
1、3 到 8 年的工作经验,精通 Go 语言、C 语言或 java 语言的一种。
2、熟悉分布式一致性协议,有分布式系统开发经验。
3、熟悉微服务架构,RPC 的基本原理、gRPC、pb 等原理和使用,加分。
4、热爱技术,有较强的学习能力、良好的团队合作能力、抗压能力。
wc951
2019-12-20 10:50:24 +08:00
其实 soa 和微服务有个毛区别,都是瞎造概念,搞出个中心化的 api 网关和原来的 esb 本质都是一个东西,也就是 service mesh 结合服务容器化有点新东西

这是一个专为移动设备优化的页面(即为了让你能够在 Google 搜索结果里秒开这个页面),如果你希望参与 V2EX 社区的讨论,你可以继续到 V2EX 上打开本讨论主题的完整版本。

https://www.v2ex.com/t/630386

V2EX 是创意工作者们的社区,是一个分享自己正在做的有趣事物、交流想法,可以遇见新朋友甚至新机会的地方。

V2EX is a community of developers, designers and creative people.

© 2021 V2EX