这是一个创建于 1932 天前的主题，其中的信息可能已经有所发展或是发生改变。
坐标武汉，目前在一家小的不能再小的公司做服务端，业务就是医疗相关。数据库、Java 服务端都是我在做，另外 Java 基本就我一个人在搞，要用什么全都可以自己决定，现在项目慢慢多起来了，感觉现在的架构(我觉得就算不算架构，全是我用 spingboot+mybatis+db 做的项目)已经满足不了需求了。目前公司版本管理也算是形同虚设，另外接下来一个项目可能需要用上分布式了，我准备学习下 springcloud 然后用在项目上。 发帖是想求助下各位大佬，如何能够让自己后端的设计适应不同客户提出的定制化需求，怎样能够做产品而不是单个的项目。现在的后端设计动不动就要加业务表或者修改业务表，有没有一些设计思想能指点一下？另外版本管理方面用了 maven+git，但是也是凭借着一点在前公司使用的经验，感觉理解尚浅，请大家指点一二！
 |
1
notreami 2019-08-14 11:56:39 +08:00
费那么多话，核心关注是：后端的设计适应不同客户提出的定制化需求。
流程编排啊 |
 |
2
guodastanson OP @notreami 流程编排，学习了，敢问有什么好的资料能推荐下否？
|
 |
3
taogen 2019-08-14 12:53:40 +08:00 via Android
|
 |
4
MotherShip 2019-08-14 13:09:19 +08:00
费那么多话，核心关注是：后端的设计适应不同客户提出的定制化需求。
哪来的 这么多分布式微服务，缓存加上了没，数据库做读写分离了没就微服务 |
 |
5
sandrew1945 2019-08-14 13:17:20 +08:00
感觉用不上分布式
|
 |
6
HuHui 2019-08-14 13:18:28 +08:00 via Android
武汉最近什么情况，搞医疗的，搞电商的突然这么多?
|
|
7
guodastanson OP @sandrew1945 要用的，后面有个项目要求部署到三台 server 上，随时有两台备用，不用分布式怎么弄
|
|
8
guodastanson OP @HuHui 武汉没啥情况，小公司多的很，另外项目都不在武汉。实际上就是在武汉做开发，销售啥的都在别的地方
|
|
9
guodastanson OP @MotherShip 这个跟缓存没关系。。
|
|
10
guodastanson OP @MotherShip 提这个问题不在于性能，而在与设计，怎么能往产品方向走而不是做一个个项目
|
|
11
guodastanson OP @taogen 您这个回答比较靠谱，上面有几个哥们会错意了
|
 |
12
arthas2234 2019-08-14 14:09:23 +08:00
@guodastanson 你这个是集群吧，不是分布式
|
 |
13
lllllliu 2019-08-14 14:12:20 +08:00  1
自建 GITLAB 版本管理，然后根据技术栈再配置 CI/CD，容器化也可以，就可以方便编排了，流程也全部可以定制化了。
如果你以后做的项目都差不多，可以通过微服务的拆解组合，或者 DOCKER IMAGE 定制来做呀。 |
|
14
guodastanson OP @arthas2234 是的，集群。但是我们整个的叫智慧医疗的项目实际是很多子项目，之间也有联系，我觉得可能要用上分布式的设计，后续能选择上部分项目或者全部，但是不影响整体功能。
|
 |
15
snappyone 2019-08-14 14:30:43 +08:00
@guodastanson 你这个离分布式有点远啊，还有 spring cloud 这东西也不是学一学就用的啊，一整套基础架构得有啊，建议还是先逐渐优化吧，前面几层说的缓存、分库分表，消除单点，提高性能稳定性
|
|
16
MotherShip 2019-08-14 14:43:38 +08:00
@guodastanson #10 设计和 spring cloud 更扯不上关系了，坛子里我记得前段时间有人讨论过这种根据一大堆客户定制小需求的场景可以看看
|
|
17
guodastanson OP @snappyone 目前的数据量基本上不需要考虑性能的问题，读写分离用不上，缓存倒是在部分地方用了，比如院方 api 需要的 token 缓存了。
我觉得最主要的问题是以现在的设计分支会越来越多，我想解决的就是一套东西应对多种需求，就像接口和实现类一样，我有新的医院要用这套东西只需要做轻微的适配工作而不是重新搞一堆东西出来。 |
|
18
guodastanson OP @MotherShip 有搜索关键字么？
|
 |
19
cpyhaha 2019-08-14 15:13:24 +08:00 via Android
NGINX 代理？
|
 |
20
kkjinping 2019-08-14 15:27:38 +08:00
抽象最核心、最底层的基础服务出来，其他的不同业务和需求单独开发服务，核心数据都在底层服务根据需求方字段隔离。
|
|
21
kkjinping 2019-08-14 15:28:10 +08:00 1
你的问题不是技术架构其实是业务架构的设计
|
 |
22
warcraft1236 2019-08-14 15:30:49 +08:00
用微服务是为了解耦，在复杂业务场景下才会比较有收益，不然干嘛要上微服务
|
|
23
kkjinping 2019-08-14 15:32:29 +08:00 2
具体点的步骤：
1：梳理需求，对各种需求抽取共性，把基础服务、核心服务，抽象出来，做好一定程度的扩展性，数据方面根据需求方这种字段做数据隔离。 2：非共性的业务，单独开发各自的业务服务，如果基础服务和核心服务的表不支持的部分，单独设计需求扩展表。 3：以上是业务架构。其实这种业务架构，确实比较适合做服务化，基础核心是一套服务，各自的业务服务是一套。 |
|
24
guodastanson OP @kkjinping 对的，就是业务架构设计问题。在公司都找不到人讨论问题！
第二点说的挺好的，实际操作过程中，大部分数据和业务逻辑是可以通用的，比如说病房系统就是以病床信息为核心的，但是经常要扩展一堆边边角角的属性。 我原来设计的备用属性 property1,property2 到 property4 都用上了，我感觉这种不明确的设定非常蠢，虽然较为灵活。另外其实我已经在用扩展的表了，但是感觉这是个无底洞。 |
|
25
arthas2234 2019-08-14 16:13:15 +08:00
|
 |
26
luozic 2019-08-14 16:30:08 +08:00
DDD +六边形架构+微服务 当然前提是业务足够复杂。
|
 |
27
x7395759 2019-08-14 16:51:21 +08:00
|
 |
28
br00k 2019-08-14 17:02:04 +08:00 via iPhone
jhipster 真香
|
 |
29
securityCoding 2019-08-14 17:05:08 +08:00
不用考虑这么多 , 微服务的前提是有强力懂运维开发的团队,不然会搞死人
|
 |
30
rayu 2019-08-14 19:57:07 +08:00 via Android
佩服楼主一个人搞定后端全套
|
 |
31
saulshao 2019-08-14 21:26:22 +08:00
其实，从项目走向产品化一点也不神秘。一开始所有的软件都是从项目产生的。
所谓高度定制化的软件产品其实就是项目。 面向特定行业的软件其实都是从项目演化来的。 我认为，软件的功能其实就是一整套对于具体业务支持的代码实现，目前看来包括用户界面+业务逻辑+数据存储。 软件项目和软件产品的区别，其实在于对于不同业务的支持能力。 所以你会看到，大多数的软件产品其实会专注比较简单而重要的功能，而软件项目则会让开发者感觉自己对于功能实现没有支配权。但是最终的目标，其实都是要支持相应的业务运作。为此，行业软件现在有 2 个发展方向： 1. 实现尽可能多的功能，以使得自己的软件能满足尽可能多的用户需求，这里需要指出的是，行业软件的需求其实来之不易。 2. 只实现经过筛选的主要功能，在提供给不同的用户使用时，进行针对性的定制化开发。 思路其实就是: 1. 找出哪些功能应该是核心（其实就是很多项目都要反复使用的功能），用大量的精力管理这些功能，每次修改这些功能的时候，都异常谨慎，同时对这些功能保持完整的文档追踪。 2. 为了项目实现新功能的时候，就把新功能视为扩展，只有在发现这些新功能用到很多个项目上才考虑整合到核心功能中。 从实现技术上来看，其实今天大家在讨论的所谓先进技术，在楼主所处的行业很难用得上。倒是可以考虑引入一些可以加快开发和部署速度的方法，以降低工作量，有更多的时间来考虑产品转化。 不要怕修改数据库，与修改代码的代价比，修改数据库根本不算事。所以我一直不推荐搞所谓的预留字段，对于 Oracle 这样的公司搞的那种预留 Property1~propertyN 这样的作法，我一直嗤之以鼻，因为这并不能避免变更，纯粹增加了后期维护的难度。 |
 |
32
Takamine 2019-08-15 12:36:28 +08:00 via Android
不知道楼主工作多久了，如果还是一个人挑大梁，建议分布式什么的，想都不要想。_(:з」∠)_
|
 |
33
vjnjc 2019-08-15 15:52:30 +08:00
分布式是为了性能的吧，看你的描述是新需求太多太杂，解决办法不是应该招人么。。。
|
|
34
guodastanson OP @vjnjc 招人我又决定不了，不过最近是打算问问一个在以前公司带的实习生，有没兴趣过来一起搞
|
|
35
guodastanson OP @rayu 去年还做个安卓 app 你敢信？从没搞过安卓的被逼着用 webview 搞了个 app，实际就是 app 里套了个网址那种感觉
|
|
36
guodastanson OP @x7395759 学习一波，马来人先马起来
|
|
37
guodastanson OP @Takamine 好的好的，我尽量再哄个人一起帮我做 o(*￣︶￣*)o
|
|
38
guodastanson OP @securityCoding 听你们这么一说我肯定不会动这念头了
|
|
39
guodastanson OP @x7395759 你发的这是好东西啊
|
|
40
x7395759 2019-08-16 10:59:46 +08:00
@guodastanson 加入收藏夹，好好弄一年，技术方面就不愁了
|
|
41
guodastanson OP @x7395759 已经 star，慢慢 watch
|
Select Language