这是一个创建于 1985 天前的主题，其中的信息可能已经有所发展或是发生改变。
实在想不出有什么大的革命
 |
1
86091566 2019-06-19 10:17:06 +08:00
能想到未来一个趋势就是直接托管服务，运维监控备份安全弹性扩展等全部交给云服务商，这样公司只需要专注于开发业务代码的程序员就可以了
|
 |
2
Zakun 2019-06-19 10:18:40 +08:00
不是。
|
 |
3
chenqh 2019-06-19 10:19:35 +08:00
感觉微服务还是大公司用的多把，小公司用微服务监控跟不上
|
 |
5
baozijun 2019-06-19 10:22:49 +08:00
想不出来应该是因为你没接触过. 1L 所说的就是 AWS lambda...
|
 |
6
arrow8899 2019-06-19 10:23:37 +08:00
SOA->微服务->Severless
|
 |
7
artandlol 2019-06-19 10:23:40 +08:00 via Android
更适合人类分工协作。
当你在频道维护一个系统的时候你会发现，微服务的模式更安全，影响更小。现在的系统，比如大数据，你没办法去控制每个模块的流量，比如微博的评论模块，图像模块，做到精细化管理 |
 |
8
janxin 2019-06-19 10:23:49 +08:00
不是
|
 |
9
daimen 2019-06-19 10:24:12 +08:00
不是。
|
 |
10
luzemin 2019-06-19 10:24:51 +08:00
每一个技术的出现都有它的必然性，项目规模达到一定规模后，必然会分而治之，微服务就是响应这种趋势提出来的解决方案。被广泛的采用就证明了它的正确性。
再来说炒作的问题，微服务是马丁老头提的，他是 thoughtworks 首席科学家，而 thoughtworks 对技术的营销和推广，一直都存在炒作的成分。可以说是技术领域，营销做得最好的。 （个人观点，对马丁老头无限致敬，对 thoughtworks 推动技术的贡献也无限致敬） |
|
11
artandlol 2019-06-19 10:28:38 +08:00 via Android
接触 istio 的人都知道，serverless 和 faas 都得关注 service mesh，所以怎 service mesh 的好处在哪里
|
 |
12
vjnjc 2019-06-19 10:29:00 +08:00 via Android
感觉 soa 和微服务这样概念性的东西不能驾驭啊。。。
|
 |
13
liuxey 2019-06-19 10:30:44 +08:00
Azure Functions，AWS Lambda，GCP Functions 可能就是发展方向吧
但现阶段微服务还是主流，不过想要驾驭好微服务也不简单 |
 |
14
msl12 2019-06-19 10:31:25 +08:00
分而治之是必然出现的技术潮流，将是以后的主流架构
|
 |
16
AngryPanda 2019-06-19 10:34:03 +08:00
serverless 有公司在大规模使用的吗？
|
 |
17
securityCoding 2019-06-19 10:34:29 +08:00
不是 , 小公司还是别整微服务了
|
 |
18
66beta 2019-06-19 10:37:51 +08:00 via Android
卖 vps 的还称自己为 云计算
|
 |
19
ylw 2019-06-19 10:40:31 +08:00
就是 系统模块化+人员外包 对方只需付款+使用产品 改个名字只是为了营销
|
 |
20
iyaozhen 2019-06-19 10:43:00 +08:00 via Android  1
炒作不是炒作，但没有金刚钻不要揽瓷器活。没有痛点不要强上
配套的技术、设施要求很高。 |
 |
21
ghos 2019-06-19 10:44:01 +08:00 4
 我要吐槽我们公司的微服务，搞了十几个 springboot 分别部署就叫做微服务了，部署麻烦的要死，互相调用靠写 httpclient，这就是山寨微服务的搞法。我觉得 微服务首先要解决 日志 监控 部署 事务 这几个问题才上不然真的是无比蛋疼。 |
 |
22
txwd 2019-06-19 10:49:17 +08:00
可以参考区块链技术是怎么被玩出花来的
|
|
24
luzemin 2019-06-19 10:50:15 +08:00
@ghos #21 同意。不过好多公司因为各种制约，都是伪微服务、伪 DDD 等等。之前 git 火的时候，公司要求将 SVN 换成 git，换了之后，还是当 SVN 用。
|
 |
25
fish2050 2019-06-19 10:50:39 +08:00
@ghos 我写的微服务框架满足你的需求，部署也简单， nutzwk.wizzer.cn
|
 |
27
chendy 2019-06-19 10:51:01 +08:00
不是炒作，但是没有刚需或者没有足够实力不要上
|
 |
28
Cbdy 2019-06-19 10:52:17 +08:00 via Android
还有云原生
|
 |
29
dyllanwli 2019-06-19 10:57:56 +08:00
不是的 serverless 是真的香
|
 |
30
hzgit 2019-06-19 11:30:41 +08:00
有没有炒作倒是不清楚，不过微服务肯定不是凭空拍脑袋设计出来的，而是在业务体量快速增长的现实逼迫下发展、演进出来的。
so，什么又是革命呢？无非是不得不为而已。 |
 |
31
szq8014 2019-06-19 11:33:45 +08:00
得看项目需求，如果就一普通项目，没啥并发，没啥瓶颈，单体项目就妥妥的最合适。
|
 |
32
lazyfighter 2019-06-19 11:36:42 +08:00
看看微服务设计那本书你就理解了，很多公司的组织架构都是根据服务来的
|
 |
33
hellojl 2019-06-19 11:44:21 +08:00
不是炒作，但是能从微服务中获得收益的项目，和有必要从微服务中获得收益的项目并不多，这个和微服务宣传的火热程度并不匹配
|
 |
35
l00t 2019-06-19 12:37:50 +08:00
分不分，复杂度都在那里，不在这里解决就在另一个地方解决，并不会因为分治就把复杂度给消除了的。
|
 |
36
lihongjie0209 2019-06-19 12:41:22 +08:00
微服务的是对运维的挑战. 运维跟不上, 都是扯淡.
|
 |
38
Varobjs 2019-06-19 13:03:16 +08:00 via Android
@lihongjie0209 有的没运维就开搞呢，反正痛苦是下面业务开发的，不是决策者。
|
 |
40
Erroad 2019-06-19 13:42:35 +08:00
@ghos #21 rpc 用什么是个问题，但是还不是大问题。大问题你也说的很明显了，拆分不合理，部署 监控啥啥的都跟不上才是问题
|
 |
41
notreami 2019-06-19 13:59:47 +08:00
QPS 上百后，价值就很明显了。
|
 |
42
Banxiaozhuan 2019-06-19 15:10:01 +08:00
如果你所在的公司没有用到微服务， 应该考虑一下几个问题：
1、 流量不够大。 2、 业务简单， 维护代码量少。 （程序员少）。 个人觉得 微服务最大的优势在于，每个程序员之间的代码解耦。 |
 |
43
wentaoliang 2019-06-19 16:50:37 +08:00
@notreami 上百。。。。单机 php 都能跑起来。。
|
|
44
notreami 2019-06-19 17:34:33 +08:00
@wentaoliang 是啊，业务 QPS 上百后，就会考虑可用性，稳定性。怎么提升人效、减少阻塞。
|
 |
45
q397064399 2019-06-20 10:51:08 +08:00 1
在实际生产使用中有很大炒作嫌疑， 就目前我接触到很多在中小公司从业的同事朋友来说，
Micro Service 真的夸大其词了 第一大块，Micro Service 是有使用代价的，基础设施跟不上，在调试 /运维 /发布 /开发 /验证 等各个环节都是要大幅度降低生产效率的。 恰好 中小型公司对改进开发效率没有任何动力， 因为很多所谓的互联网公司，业务才是王道，各级开发领导都是背着业务开发任务指标的， 基本上很难有动力做这些基础设施的改进。 1.我知道的 目前就有 3 种 httpclient 在我们服务中使用 ， 其中还有一个 3 年前封装的半成熟的 httpclient 也在使用当中，既没有文档 又没有注释， 正确的使用方式全靠猜解跟参照过去的历史遗留代码。 2.模块化依赖做得很不合理，我不知道谁在哪里看了几篇 maven 的最佳实践，硬是要把 maven 默认的 scope 尽量换成 provided，虽然 Java 本身是一门静态语言，但实际上有很多动态特性，使用 provided 做 scope 很多时候导致动态序列化的时候 ClassNotFoundException，测试一方面无法保证所有的代码路径都被测试到，只能把这种依赖问题就被推迟了线上，目测未来要擦很多次屁股，本来 maven 推荐使用最短依赖路径版本来取胜，通过 exclude 来排除依赖冲突，到了我们这里就全变了。 3.服务间的接口不存在静态检查了，需要人工保证接口参数 /版本 一致，人这种东西，没有规章流程，就很容易出问题，遗漏是在所难免的，导致很多时候晚上发布，不同的团队在线上一起来修各种 BUG。 4.脱裤子放屁的事情太多，consumer 服务 监听消息队列 或者 task 服务 定时触发任务，然后又将消息的数据通过 http 调用 传回给 对应的业务服务，实际处理业务运算的仍然是 业务服务，中间加了一层脱裤子放屁的 task consumer 服务，task 配合的定时调度框架既无法在 task 服务中执行上下文中监视任务执行过程（因为真正执行业务代码的在 对应的业务服务里面 task consumer 没有 mapper 无法直接跟数据库打交道） task consumer 访问业务服务 通过 http 调用 经常直接超时，从而导致定时调度框架根本无法判断任务是否执行成功，最后导致定时任务调度框架的后台日志功能 完全变成摆设，如果想查看定时任务的执行结果 只能每天查看打印在阿里云的业务服务系统的日志。 第二大块， 1. 拆分不合理 导致调用网跟蜘蛛网一样混乱，拆分没有可行的原则，导致很多本应该拆分到对应服务的领域模型，全被美名其曰弄到基础服务里面了，实际上所谓的基础服务 既没有边界上下文 又没有领域定义，是个啥都能往基础服务里面装，结果将商品系统里面的 sku product 商品属性 全往基础服务里面装，整个商品系统服务 定价系统服务 成了一个空架子，每次干啥都要往基础服务里面取东西，而整个拆分的决策在一开始是非常不成熟的，最后由于各个系统调用的混乱的原因，基本上不太可能再对服务做拆分演化了，同之前的理由，由于业务压力，技术方面只能是继续腐烂下去，不存在改进的可能，开发人员只能在这种泥潭里面继续挣扎 |
Select Language