求助(空手套架构)来了,服务端大佬进来看看！

[guodastanson]

坐标武汉，目前在一家小的不能再小的公司做服务端，业务就是医疗相关。数据库、Java 服务端都是我在做，另外 Java 基本就我一个人在搞，要用什么全都可以自己决定，现在项目慢慢多起来了，感觉现在的架构(我觉得就算不算架构，全是我用 spingboot+mybatis+db 做的项目)已经满足不了需求了。目前公司版本管理也算是形同虚设，另外接下来一个项目可能需要用上分布式了，我准备学习下 springcloud 然后用在项目上。 发帖是想求助下各位大佬，如何能够让自己后端的设计适应不同客户提出的定制化需求，怎样能够做产品而不是单个的项目。现在的后端设计动不动就要加业务表或者修改业务表，有没有一些设计思想能指点一下？另外版本管理方面用了 maven+git，但是也是凭借着一点在前公司使用的经验，感觉理解尚浅，请大家指点一二！

[notreami]

费那么多话，核心关注是：后端的设计适应不同客户提出的定制化需求。
流程编排啊

[guodastanson]

@notreami 流程编排，学习了，敢问有什么好的资料能推荐下否？

[taogen]

https://yq.aliyun.com/articles/772

[MotherShip]

费那么多话，核心关注是：后端的设计适应不同客户提出的定制化需求。

哪来的 这么多分布式微服务，缓存加上了没，数据库做读写分离了没就微服务

[sandrew1945]

感觉用不上分布式

[HuHui]

武汉最近什么情况，搞医疗的，搞电商的突然这么多?

[guodastanson]

@sandrew1945 要用的，后面有个项目要求部署到三台 server 上，随时有两台备用，不用分布式怎么弄

[guodastanson]

@HuHui 武汉没啥情况，小公司多的很，另外项目都不在武汉。实际上就是在武汉做开发，销售啥的都在别的地方

[guodastanson]

@MotherShip 这个跟缓存没关系。。

[guodastanson]

@MotherShip 提这个问题不在于性能，而在与设计，怎么能往产品方向走而不是做一个个项目

[guodastanson]

@taogen 您这个回答比较靠谱，上面有几个哥们会错意了

[arthas2234]

@guodastanson 你这个是集群吧，不是分布式

[lllllliu]

自建 GITLAB 版本管理，然后根据技术栈再配置 CI/CD，容器化也可以，就可以方便编排了，流程也全部可以定制化了。
如果你以后做的项目都差不多，可以通过微服务的拆解组合，或者 DOCKER IMAGE 定制来做呀。

[guodastanson]

@arthas2234 是的，集群。但是我们整个的叫智慧医疗的项目实际是很多子项目，之间也有联系，我觉得可能要用上分布式的设计，后续能选择上部分项目或者全部，但是不影响整体功能。

[snappyone]

@guodastanson 你这个离分布式有点远啊，还有 spring cloud 这东西也不是学一学就用的啊，一整套基础架构得有啊，建议还是先逐渐优化吧，前面几层说的缓存、分库分表，消除单点，提高性能稳定性

[MotherShip]

@guodastanson #10 设计和 spring cloud 更扯不上关系了，坛子里我记得前段时间有人讨论过这种根据一大堆客户定制小需求的场景可以看看

[guodastanson]

@snappyone 目前的数据量基本上不需要考虑性能的问题，读写分离用不上，缓存倒是在部分地方用了，比如院方 api 需要的 token 缓存了。
我觉得最主要的问题是以现在的设计分支会越来越多，我想解决的就是一套东西应对多种需求，就像接口和实现类一样，我有新的医院要用这套东西只需要做轻微的适配工作而不是重新搞一堆东西出来。

[guodastanson]

@MotherShip 有搜索关键字么？

[cpyhaha]

NGINX 代理？

[kkjinping]

抽象最核心、最底层的基础服务出来，其他的不同业务和需求单独开发服务，核心数据都在底层服务根据需求方字段隔离。

[kkjinping]

你的问题不是技术架构其实是业务架构的设计

[warcraft1236]

用微服务是为了解耦，在复杂业务场景下才会比较有收益，不然干嘛要上微服务

[kkjinping]

具体点的步骤：
1：梳理需求，对各种需求抽取共性，把基础服务、核心服务，抽象出来，做好一定程度的扩展性，数据方面根据需求方这种字段做数据隔离。

2：非共性的业务，单独开发各自的业务服务，如果基础服务和核心服务的表不支持的部分，单独设计需求扩展表。

3：以上是业务架构。其实这种业务架构，确实比较适合做服务化，基础核心是一套服务，各自的业务服务是一套。

[guodastanson]

@kkjinping 对的，就是业务架构设计问题。在公司都找不到人讨论问题！
第二点说的挺好的，实际操作过程中，大部分数据和业务逻辑是可以通用的，比如说病房系统就是以病床信息为核心的，但是经常要扩展一堆边边角角的属性。
我原来设计的备用属性 property1,property2 到 property4 都用上了，我感觉这种不明确的设定非常蠢，虽然较为灵活。另外其实我已经在用扩展的表了，但是感觉这是个无底洞。

[arthas2234]

@guodastanson
这个需要你充分了解业务，抽出公用业务，剩下客户定制的需求通过配置或者定制化模块来解决
表设计也是：主表+扩展表，扩展表使用主表名_公司名

[luozic]

DDD +六边形架构+微服务 当然前提是业务足够复杂。

[x7395759]

楼主有好机会

https://github.com/xingshaocheng/architect-awesome

[br00k]

jhipster 真香

[securityCoding]

不用考虑这么多 , 微服务的前提是有强力懂运维开发的团队,不然会搞死人

[rayu]

佩服楼主一个人搞定后端全套

[saulshao]

其实，从项目走向产品化一点也不神秘。一开始所有的软件都是从项目产生的。
所谓高度定制化的软件产品其实就是项目。
面向特定行业的软件其实都是从项目演化来的。
我认为，软件的功能其实就是一整套对于具体业务支持的代码实现，目前看来包括用户界面+业务逻辑+数据存储。
软件项目和软件产品的区别，其实在于对于不同业务的支持能力。
所以你会看到，大多数的软件产品其实会专注比较简单而重要的功能，而软件项目则会让开发者感觉自己对于功能实现没有支配权。但是最终的目标，其实都是要支持相应的业务运作。为此，行业软件现在有 2 个发展方向：
1. 实现尽可能多的功能，以使得自己的软件能满足尽可能多的用户需求，这里需要指出的是，行业软件的需求其实来之不易。
2. 只实现经过筛选的主要功能，在提供给不同的用户使用时，进行针对性的定制化开发。
思路其实就是:
1. 找出哪些功能应该是核心（其实就是很多项目都要反复使用的功能），用大量的精力管理这些功能，每次修改这些功能的时候，都异常谨慎，同时对这些功能保持完整的文档追踪。
2. 为了项目实现新功能的时候，就把新功能视为扩展，只有在发现这些新功能用到很多个项目上才考虑整合到核心功能中。
从实现技术上来看，其实今天大家在讨论的所谓先进技术，在楼主所处的行业很难用得上。倒是可以考虑引入一些可以加快开发和部署速度的方法，以降低工作量，有更多的时间来考虑产品转化。
不要怕修改数据库，与修改代码的代价比，修改数据库根本不算事。所以我一直不推荐搞所谓的预留字段，对于 Oracle 这样的公司搞的那种预留 Property1~propertyN 这样的作法，我一直嗤之以鼻，因为这并不能避免变更，纯粹增加了后期维护的难度。

[Takamine]

不知道楼主工作多久了，如果还是一个人挑大梁，建议分布式什么的，想都不要想。_(:з」∠)_

[vjnjc]

分布式是为了性能的吧，看你的描述是新需求太多太杂，解决办法不是应该招人么。。。

[guodastanson]

@vjnjc 招人我又决定不了，不过最近是打算问问一个在以前公司带的实习生，有没兴趣过来一起搞

[guodastanson]

@rayu 去年还做个安卓 app 你敢信？从没搞过安卓的被逼着用 webview 搞了个 app，实际就是 app 里套了个网址那种感觉

[guodastanson]

@x7395759 学习一波，马来人先马起来

[guodastanson]

@Takamine 好的好的，我尽量再哄个人一起帮我做 o(*￣︶￣*)o

[guodastanson]

@securityCoding 听你们这么一说我肯定不会动这念头了

[guodastanson]

@x7395759 你发的这是好东西啊

[x7395759]

@guodastanson 加入收藏夹，好好弄一年，技术方面就不愁了

[guodastanson]

@x7395759 已经 star，慢慢 watch