说两个特普遍，也特烂的架构

[hunhunabc]

1.把service层提取出来做成rpc独立部署对内提供接口，web应用全通过rpc调service；
2.多类用户，如管理端、B端、C端，提供多个web服务（java的三大特性晓得吧，抽象会不会）；

[qybao]

从LZ的问题来看，我觉得LZ可能是个不想变通的人，只会做（或者只希望做）自己会的东西，新的东西不愿去学，然后就抱怨新的东西不好，这种心态要调整。

微服务是个趋势，把大的系统拆成小系统，小系统之间放到集群里各小系统用rpc调用，这是很常见的架构
所以
1.把service层提取出来做成rpc独立部署对内提供接口，web应用全通过rpc调service；
对外可以是web应用，但是对内rpc效率可能要高于web应用（web的connection创建可能很耗时，rpc远程调用效率近似于本地调用），所以集群内部微服务为了更高效的相互调用是不是用rpc跟合适一些？然后对外提供一个api网关是web应用就可以了。

2.多类用户，如管理端、B端、C端，提供多个web服务（java的三大特性晓得吧，抽象会不会）；
如果所有的客户端都用同一个服务，那服务出问题了，是不是所有的客户端都不能处理业务了？划分为多个服务，就是为了避免某个服务坏了，不影响其他客户端利用其他服务。再说了，多个服务未必就是多个程序，同一个程序打包成一个jar包被多个tomcat同时使用，每个tomcat就是一个web服务，而且互相独立（一个坏了不影响另一个正常工作），这是java三大特性的抽象能解决的问题吗？

所以在讨论烂不烂之前，先问问自己是否真的理解了这些架构的意义。

[鸡窝里的毛]

看业务需求和项目规模，不能一概而乱。

面向对象也不是万能的，要不然也没python什么事了。

[hunhunabc]

引用 1 楼 qybao 的回复:

从LZ的问题来看，我觉得LZ可能是个不想变通的人，只会做（或者只希望做）自己会的东西，新的东西不愿去学，然后就抱怨新的东西不好，这种心态要调整。 微服务是个趋势，把大的系统拆成小系统，小系统之间放到集群里各小系统用rpc调用，这是很常见的架构

你可别逗了，把微服务做成纯rpc，所以说你们这种架构特别普遍还特烂，做的烂的还以为自己是对的。。。 你知道什么是微服务？？你所说的个小系统就是，但你却不会用，烂还以为自己是对的

[qybao]

就你会用？那你到说说你的好架构啊，说出来让大家惊叹一下？ 就你这种心态，自己会的都是好的，不会的就是烂，不愿接受新事物新挑战。 如果人人都像你一样一层不变，那么IT就没有什么新发展了。 给你回复只是想劝劝你调整自己的心态，不是来和你吵架的，你的架构烂不烂跟我也没半毛钱关系，你觉得你牛你就自己推翻你的老板你的客户，犯不着在这里看到别人意见相左就乱咬。

[hunhunabc]

引用 4 楼 qybao 的回复:

就你会用？那你到说说你的好架构啊，说出来让大家惊叹一下？ 就你这种心态，自己会的都是好的，不会的就是烂，不愿接受新事物新挑战。

你是哪看出我不愿接受新事物？？ 微服务的多个小系统是靠网关做聚合组成一个应用，如果你是把rpc再包一层web做聚合，那是好是坏我就不说了。 网上的开源springcloud示例，基本只针对一类用户的微服务。。如果想微服务应用面向多类用户，该怎么做？？烂架构之2中已解答

[hunhunabc]

引用 7 楼 qybao 的回复:

[quote=引用 5 楼 hunhunabc 的回复:] 对于问题1，【把rpc再包一层web做聚合】，好吧，姑且这么理解，那为什么要包一层？ 首先系统分外部和内部，外部就是提供接口和外部的系统环境通信（就你所谓的包一层web），内部就是系统里面各个子系统之间的调用。

你对于问题1的回复，看出你可能对微服务中的网关使用不深。对外暴露的通过网关暴露出去就好，一个服务即可向外提供web，也可以向内提供rpc，两则不冲突。。 对于问题2，讲细点，抽象的是用户。。管理员、卖家、卖家都需要查看物流信息接口，向前端提供一个接口即可；对于未登录的不能查看；如果要增加一个用户类型，将接口开放给这类用户即可；查看订单详情，按业务逻辑，逻辑相同的用户类型用一个接口。。。所以微服务的服务提供的是能力，用户类型、流控只是在能力的使用上加一定的资源控制、权限控制。。

[hunhunabc]

我说的烂都是指技术架构设计烂，影响到这类的设计者，抱歉了。。 就这样，不扯了。。。

[qybao]

引用 8 楼 hunhunabc 的回复:

[quote=引用 7 楼 qybao 的回复:][quote=引用 5 楼 hunhunabc 的回复:]

对于问题1，【把rpc再包一层web做聚合】，好吧，姑且这么理解，那为什么要包一层？
首先系统分外部和内部，外部就是提供接口和外部的系统环境通信（就你所谓的包一层web），内部就是系统里面各个子系统之间的调用。

你对于问题1的回复，看出你可能对微服务中的网关使用不深。对外暴露的通过网关暴露出去就好，一个服务即可向外提供web，也可以向内提供rpc，两则不冲突。。
对于问题2，讲细点，抽象的是用户。。管理员、卖家、卖家都需要查看物流信息接口，向前端提供一个接口即可；对于未登录的不能查看；如果要增加一个用户类型，将接口开放给这类用户即可；查看订单详情，按业务逻辑，逻辑相同的用户类型用一个接口。。。所以微服务的服务提供的是能力，用户类型、流控只是在能力的使用上加一定的资源控制、权限控制。。

[/quote]

别人对网关使用不深，就你深，好不？第一个问题我第一次回答就告诉你对外用个api网关提供服务即可，对内用rpc。你也觉得两者不冲突，那你所谓的烂从何谈起？
对于问题2，你的思维一直停留在业务设计层面，这跟多个用户对应多个服务并不冲突。A的类能否被B重用，那是类设计的问题，但是A，B两种用户需要两个服务这是有必要的。比如A是面向微信支付服务，B是面向支付宝支付服务，设计上A和B也许有共通类，但是部署服务A和B就应该分开（AB之上或许还可以抽出一层共通接口服务层，这还又多了个服务），这不比你AB合在一起部署一个服务灵活（理由上面说过了）？。
你一直在抱怨烂，却提不出有力的论据支持，很难有说服力。你如果觉得烂，你就坚持抵制到底好了，接受不接受新事物本来就是个人自由。
不说了，到此结束。。。

[tianfang]

这个事儿算架构吗 呵呵

[qybao]

引用 5 楼 hunhunabc 的回复:

你是哪看出我不愿接受新事物？？
微服务的多个小系统是靠网关做聚合组成一个应用，如果你是把rpc再包一层web做聚合，那是好是坏我就不说了。
网上的开源springcloud示例，基本只针对一类用户的微服务。。如果想微服务应用面向多类用户，该怎么做？？烂架构之2中已解答

从哪看出来的？
从你说话的语气就能感觉到你抵触的情绪。而且，你只是在吐槽烂，却从未从正面提出证明烂的有力论据（议论文三要素，论点，论据，论证），说明你对新事物还没有足够的理解，找不出新事物的破绽，只是从个人开发习惯去抱怨种种不适应。
就你提出的2点论据，根本站不住脚，支持不了你的烂的论点。

对于问题1，【把rpc再包一层web做聚合】，好吧，姑且这么理解，那为什么要包一层？
首先系统分外部和内部，外部就是提供接口和外部的系统环境通信（就你所谓的包一层web），内部就是系统里面各个子系统之间的调用。
以前的老系统只需关注外部，不需要关注内部（因为内部都集成在一个大系统，各个小系统集中在一个服务里，A调用B只是简单的Anew一个B的service调用其方法就可以，肉眼看不到A调用B），所以你只看到了外面包装的web层，你就误以为系统只有这么简单的一层。
现在的新系统变了，系统内部的大系统划分为小系统，各个小系统不在运行于同一个服务，A调用B就不能像以前那样new一个B的service调用其方法就可以了，A和B要通过网络通信来交互，那么A和B的通信怎么实现？
先来看个例子，假设你和父母同住在一个房子里构成一个大系统，你，你父亲，你母亲分别是各个小系统，你的朋友在放在外面用手机给你打了个电话（向你发起web请求），你接了电话跟你朋友聊着聊着，然后你朋友突然有个问题要问你父亲，此时，你一般可以采取一下措施
1 直接喊你父亲并问他问题让他回答（向你父亲发起rpc请求）
2 假设你的电话是个子母机，你把电话转到你父亲旁边的分机让你父亲直接回答你的朋友（请求转接或请求重定向）
3 你掏出手机拨打你父亲的手机在手机里问他并让他回答（向你父亲发起web请求）
不管哪种方式都能达到目的，但是对于方式2和3，很有可能你父亲在手机嘟嘟响了好几声才接电话（这就是我上面说的可能创建connection耗时），所以一般情况下采用方式1直接喊你父亲（rpc）会更高效一些。
所以，在新系统中，你不只看到了系统外部的web层包装，你还看到了系统内部的子系统A和B交互的通信实现，所以你认为系统多包装了一层。
那么好了，你觉得web包装（rpc）的烂是哪里烂？是不该用rpc实现？还是说系统内部就不应该划分（还是以前的系统一样集成在一个服务里）？
如果是觉得不该用rpc，那么这只是系统内部实现的细节问题，上面的例子可以看出，除了rpc还有其他方式，或许以后还有其他协议比rpc更优越，但不管是哪种方式，跟架构本身没关系，不能支持架构烂的论点。
如果是认为系统内部不该划分，那就说明你的思维还是停留在老系统阶段，这也是你不愿接受新事物的一个证明。

对于问题2，觉得的烂，我恰恰认为是好的地方。这也许是微服务的初衷或微服务产生的原因之一。
先来看看服务分开的好处
1 对于A，B，C客户端，也许客户不同业务不同，所以A，B，C的业务没有必要合在一个服务里（否则A业务更新，本来跟BC业务没半毛钱关系，但修改了A重新发布部署，对BC也造成了影响）。
2 A，B，C服务独立，可以独立部署升级，提供不同的服务版本（比如A服务使用2.0功能，B，C服务使用1.0功能），而且A服务升级时不影响BC服务。
3 灵活管理用户服务，比如追加一种新客户D，只要追加一种新服务D即可，不影响ABC服务（跟他们也没半毛钱关系），同样的，减少一种客户，只需要去掉一种服务即可
4 可以根据需求灵活优化服务，比如A客户多一些，需要网络流量多一些，那就给A多部署几个服务或增加集群的网络阀值，B客户少一些，那就少部署些B服务或减少集群的网络流量阀值
5 可能灵活控制服务的访问限制，比如A服务只能某段IP能访问，或者只在某段时间能访问（比如双11晚上10点开始12点结束）等等

你觉得多服务烂，那我倒想问问，你的单一服务是怎么对应以上列出的好处（或需求）的（不要光说人家烂，把你觉得好的觉得牛掰的也列举几个出来看看呗，比如怎样怎样设计一个抽象类，哇，只有继承它的类的服务就可以随时停止，随时控制流量，随时升级部署而不影响其他服务？）。
java抽象只是业务层面的设计，比如A的类在B和C能否重用，那只是类设计的问题，跟架构没有半毛钱关系，再说了，同一个jar包启动多个服务不行吗？我觉得你把业务设计和架构混为一谈了，概念不清。