有这么一个初步设想的系统架构:
1.没有采用微服务 2.后台由若干个独立的 jar 包组成(其实是一个项目按照业务拆分为多个 jar 包),每个 jar 包独立开发,使用 SpringBoot+Mybatis,但是各个 jar 包内部的技术可能不统一。 3.前台有一个网关,起到鉴权和路由的作用,网关底层由 shiro+jwt 封装实现。并在网关层面做用户登录。 4.两个 jar 包可能会有相互调用,方案是通过 HTTP 请求调用。 5.权限控制到页面(菜单)级别,控制哪些角色能看哪些页面。
请问各位大佬这样的架构有什么样的问题呢?
1
Ianchen 2019-12-19 09:11:22 +08:00
没问题, 你这设计实际上还是微服务.
|
2
uleh 2019-12-19 09:17:14 +08:00
> 4. 两个 jar 包可能会有相互调用,方案是通过 HTTP 请求调用
你这个请求加一个管理,就跟微服务的技术栈一毛一样了 是不是“微”服务就只取决于你的 jar 包的拆分粒度了 |
3
lhx2008 2019-12-19 09:17:38 +08:00 via Android 1
微服务就是用来解决你这么搞,搞出来的一堆问题,包括链路监控,负载均衡,灰度发布,横向扩展,服务发现
|
4
securityCoding 2019-12-19 09:18:18 +08:00
何不直接上 spring-cloud
|
5
fanjianhang 2019-12-19 09:22:38 +08:00
没问题,还是微服务
|
6
specita 2019-12-19 09:27:02 +08:00
我遇到的一般都是这种架构啊,java jar 包一般是用的 zk+dubbo,go 的遇到的是用 gRpc+consul
|
7
Geekerstar OP 回复一下各位大佬:
1.考虑到各方面原因暂时不直接上微服务,其实这架构是一个缩小版的微服务。 2.主要是网关、权限、登录那一块怕会有问题。 |
8
Geekerstar OP @specita 是的啊,主要是现在情况是不让用微服务的相关组件
|
9
Ianchen 2019-12-19 09:42:04 +08:00
Istio 可以了解一下, 至于权限, 登录. 你已经走微服务架构了, 这两块也可以独立一个 jar 包, 并不一定要写在网关里, 只不过你的 verify 可以在网关层面做拦截. 怕有坑不去踩你成长不了. 这对你以后架构设计也有经验帮助.
|
10
gosansam 2019-12-19 09:43:19 +08:00
跟我们情况很像,最开始 cloud 都搭建完毕,网关什么的我都写好了,突然不让用注册中心(说是直接 30W 买两台 F5 比维护这么多机器更方便。。。),直接通过 keepalived+vip+ nginx,而且还是两台机器搞这一坨,虚拟两个 ip,一个内网一个公网,也没啥毛病,反正咱也说不上话
|
11
dxpy 2019-12-19 09:56:44 +08:00
微服务太耗硬件资源,有些 B 端应用这么做没啥毛病
|
12
Geekerstar OP 还有个问题,网关那一块在这种架构下有没有什么比较好的解决方案呢?目前设计的网关这块主要作用是登录,权限认证那些
|
13
Xbluer 2019-12-19 10:09:39 +08:00
>>> 4. 两个 jar 互相调用
这一点还是慎重一点吧。任其发展下去,又是一团乱麻。 |
14
xuanbg 2019-12-19 13:02:10 +08:00
不用担心微服务的复杂度,最简单的微服务可以没有注册中心,没有配置中心,没有网关,没有限流 /熔断,不用任何微服务组件,只是把你的一个服务拆分成多个。
当然,增加一个 Eureka 提供服务的注册 /发现,然后服务间调用就可以很方便地使用 FeignClient 了。好吧,搞个 Gateway 服务做网关,实现输入输出日志审计和鉴权什么的也挺香的,而且也不费事。配置中心可以用现成的,譬如携程的 Apollo,不用也没关系,我们就没用。 至于熔断器什么的,大多数系统根本用不上,你就先不要考虑了。慢慢来吧,基本的微服务架构真的很简单。 |
15
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、热爱技术,有较强的学习能力、良好的团队合作能力、抗压能力。 |
16
wc951 2019-12-20 10:50:24 +08:00 via Android
其实 soa 和微服务有个毛区别,都是瞎造概念,搞出个中心化的 api 网关和原来的 esb 本质都是一个东西,也就是 service mesh 结合服务容器化有点新东西
|