温馨提示

精选留言(23)

• 
  LMD 置顶

  2018-01-26

  关于《微服务架构核心20讲》课程讲义（PDF 文件），学员可复制下面链接到浏览器下载获取。 http://t.cn/RQs9iTw

  

   12
• 
  探索无止境

  2018-01-14

  演化出来的，业务驱动架构的发展

  

   20
• 
  张闯

  2018-11-13

  主观上，架构是设计出来的。
  客观上，架构是演化出来的。
  架构师从一开始，就要有设计出一个好的架构的主观愿望。这个主观愿望会驱使架构师去深入地了解业务诉求（问题域）。这个主观愿望会驱使架构师在单体应用阶段就进行良好的模块划分设计，努力实现各个模块的高内聚、模块间的松耦合。为将来的微服务化打好基础。
  但是，业务是不断变化的，技术团队对业务的理解也是不断深入和全面的。因此，初始阶段设计出来的架构大概率是不符合真正的业务模型的。所以，再好的架构都不会一尘不变，都是不断演化出来的。
  所谓演化，是指某个服务会在某个阶段从单体中脱离出来。随着业务的发展，会有越来越多的服务从原来的单体或其他服务中脱离出来。一些服务之间或许还会合并成新的服务。
  架构师不能因为架构是演化出来的而不在一开始就精心设计。架构师也不能觉得架构是设计出来的，而期望在一开始就设计出完美架构。
  在业务发展的各个阶段，架构师应该综合考虑团队能力、技术复杂度、投入产出比，让架构设计永远保持合理。
  好的技术架构是合理的、而非完美的。
  

  展开

  

   14
• 
  杨波

  2018-02-03

  最终一致主要靠异步消息，事件源Event Sourcing也是一种技术，后继会开专用课程讲解

  

   13
• 
  大漠孤烟

  2018-01-26

  老师，微服务后，数据的最终一致性，是一直困扰我的问题，想听一下你的高见

  

   10
• 
  小白赵

  2018-03-15

  设计和演化都离不开，没必要把它俩放到对立面上。

  作者回复: 互联网系统一般是三分设计，七分演化，微服务是演化式架构。

  

   6
• 
  dave

  2018-12-31

  老师，100人的团队才可以考虑微服务吗？我们团队就10多个人是不是就不要考虑了？

   1

   4
• 
  颇忒妥

  2018-05-19

  单块优先逐步微服务的前提是单块本身的架构设计良好，比如按模块、按类库开发业务功能，保证业务代码之间的松耦合，可以考虑采用DDD来指导设计。如果原来的代码一团乱麻，那微服务也救不了你。

  作者回复: 对，如果团队没有能力搞定单块应用，没有基本的模块化，分层分治思维，那么也别指望微服务能成为救星

  

   3
• 
  Eyas

  2018-08-08

  课程中提到单块优先法则，主要是由于微服务架构过于复杂，前期成本会太高，生产力比单块应用较低。
  但是目前有了成熟的微服务架构开源框架，比如go-micro, gokit等等，使得微服务架构可以开箱即用，专注于业务服务。
  那么微服务架构的前期投入成本也在降低，甚至可能还比单块应用更低。
  在微服务开源框架成熟后，使用这些开源方案，在前期开发，技术栈更灵活，分工更明确。在后期几乎没有切换为微服务成本。
  这个时候，单块优先法则还适用吗？

  展开

  作者回复: 单块优先仍适用，1微服务本质不是技术问题，而是组织架构问题，你的团队和组织规模足够大需要切分微服务吗？2你对业务领域足够理解，能合理切分业务域吗？

  

   2
• 
  geeksi

  2018-10-17

  单块优先原则就是前期不推荐使用微服务的架构,随着业务扩展和架构师对整体业务理解的加深到一定程度,可以采用微服务.架构师对复杂度和生产力需要有一个权衡.

  作者回复: 同意👍

  

   1
• 
  xpisme

  2018-08-02

  架构是演化出来的。
  

  作者回复: 👍

  

   1
• 
  唐😊 木木

  2018-05-14

  一直就是类似看法。看了老师的课程更加坚定了。上来开发一个新东西的时候不要谈什么高大上的技术。就是乱拳打死老师傅。另外，极客时间可以考虑优化了，评论会导致视屏暂停，影响用户评论积极性，降低活跃度。

  作者回复: 嗯，你的建议会反馈极客时间。

  

   1
• 
  张伟波

  2018-03-12

  投入微服务的点如何衡量呀

  作者回复: 没有明确的数量化时间点，要架构师凭经验综合权衡，考虑因素主要是业务和团队规模，系统的耦合度是否影响到团队并行开发效率，影响就要解耦拆分。

  

   1
• 
  M1racle

  2018-03-12

  个人觉得架构是演化出来的，随着业务的推进，逐步演化

  作者回复: 互联网系统一般三分设计，七分演化，微服务是演化式架构。

  

   1
• 
  13671864609

  2018-01-28

  即是设计又是演化的，世间事物不是非黑即白。

  

   1
• 
  Aileen

  2018-01-22

  当然是演化出来的 没有经历过历炼的不是好架构

  

   1
• 
  秋惊蛰

  2019-08-02

  大型企业级架构都是演化出来的

  

  
• 
  Panda

  2018-11-10

  架构是演进过来的 随着业务场景 和 业务量的增长 架构也在慢慢增强

  作者回复: 对，随着业务量的增长，对架构的要求会更高，投入也会更大。

  

  
• 
  liyinda0000

  2018-08-14

  演化出来的多 设计也得贴近实际

  作者回复: 互联网分布式系统常常是三分设计，七分演化，在设计中演化，在演化中设计。

  

  
• 
  meijing0114

  2018-05-24

  按照这个思路的话，刚开始的原型还是会比较纠结的，以java为例的话，是不是一开始只能用tomcat springmvc 等等先把业务打包在一起。然后等到需要微服务了再引入spring cloud? 这样是不是刚开始就设计了一个大概率被优化掉的架构？这样的话，学习微服务架构的最佳实践意义何在呢？

  作者回复: 刚开始优先解决业务问题，架构够用就好，不要过度工程。后面要不要优化，要看业务发展具体情况。学习一方面解决当下问题，当不如果暂用不上，则为将来准备，另外学习是为拓展自己的架构视野。

  

  