LMD 置顶2018-01-26关于《微服务架构核心20讲》课程讲义（PDF 文件），学员可复制下面链接到浏览器下载获取。 http://t.cn/RQs9iTw 6
2018-03-12这个视频播放器实在太烂，怎么设计的作者回复: 会反馈极客时间，谢谢提醒🌹
28
2018-01-17架构是演化出来的，开始要保证simple原则，尽可能简单 13
2018-11-13微服务架构本质上是一种组织架构的重组。
这里说的重组，应该是指从按照职能（技术技能）来组织团队转变为按照产品（特性）来组织团队的过程。
职能团队将关注点主要放在技术上，团队成员掌握了同一个技术知识。
跨职能的特性团队将关注点放在业务和产品上，团队成员掌握了同一个产品特性的知识。
由于，团队间的沟通成本远大于团队内的沟通成本。因此，要将沟通频率更高的问题和沟通价值更高的问题放到团队内部。
由于业务是不断变化的。所以，相比于技术问题，业务问题是沟通频率更高的问题。
由于对于大部分企业来说，真正产生价值的是公司的主营业务，而非公司积累的技术专利。所以，相比于技术问题，业务问题是沟通价值更高的问题。
因此，以业务关注点来划分特性团队，相比于以技术关注来划分职能团队，会让整个企业内部的沟通效率更高，让企业更具市场竞争力。展开 10
2018-01-21微服务的团队更加专注于某类业务，迭代服务的开发。而传统的开发团队所有业务都接触，难以专注 8
2018-02-22我个人认为团队成员,自己决策者的能力来决定微服务,任何的结果都是人来触发的,水平比较低差的,代码最后的结果只能是重写重构作者回复: 恩，团队人才水平对组织和微服务架构有重大影响
4
2018-01-28分情况，有的场景下：架构是设计出来的；而有的时候是需要不断演进而来的 4
2018-01-18把原先按照职能来划分的组织打散，重新按照契合微服务的开发方式来组织。比如，原先甲属于研发团队，后来微服务来了，其中有个用户微服务，安排甲来做微服务，那甲就属于用户微服务团队了。 3
2018-06-03好架构是随着业务发展、问题暴露，不断演化来的，不可能一开始就设计出好架构出来作者回复: 正确👍
2
2018-05-19传统软件企业要交付软件给多个客户（十几个到几十个），项目周期又普遍较长（半年到两年不等），这个时候怎么规划团队呢？作者回复: 微服务较适合平台型互联网公司，传统软件企业可能还是围绕合同项目组织团队，个人在这块经验不多。
1
2018-04-15都是跨职能的微服务团队的话，应该还需要一个横向的架构在各个微服务之上的组织吗？要不然谁能看到全局呢作者回复: 可以有，比如某些公司有虚拟架构团队，但不能太重轻量即可
1
2018-04-11架构是设计出来的，再逐步跟随业务演化，演化的过程其实还是在不停的设计。作者回复: 在设计中演化，在演化中设计
1
2018-01-21讲解的非常好，前期的业务验证不一定能得到认可，成本很高，适当的权衡利弊 1- 2019-11-03平台+服务支撑业务
2019-08-20波波老师，为以后过度到微服务的目标，在一开始采用单体模式开发的时候，需要考虑功能模块的划分设计不？以方便以后微服务的实现，即不用重新实现模块作者回复: 模块化是软件设计最佳实践，可以保障软件低耦合，易于重用，今后能灵活扩展，单体和模块化并不矛盾，所以即使采用单块模式，也要提前考虑模块化设计。另外，作为架构师，系统架构设计需要有一定的提前量，其中包括模块化设计。
2019-08-02有什么样的组织架构就有什么样的系统架构反应作者回复: 对，这是康威法则(conway's law)
2019-03-09精彩！作者回复: 谢谢支持！
2019-03-01目前我们部门团队是异地两地协同开发，在沟通协调测试上面缺乏一些经验，在此模式下采用微服务开发，老师有何意见和个人看法？作者回复: 你是，微服务即使一种技术手段，也是一种组织治理方式，通过分而治之方式，达到组织团队和业务开发规模化和快速迭代的目标。异地团队协同开发，采用微服务架构，可以考虑采用契约优先(contract first)开发模式，例如grpc或spring/swagger支持契约驱动开发，开发前，两边团队定义好服务契约， 根据契约开展开发和测试，可以提升一致性和研发效率；当然团队之间良好的沟通和协作也非常重要。
2019-01-17架构设计三原则 ：合适原则 、简单原则 、演化原则。作者回复: 总结得不错！
2018-11-22从架构中来到微服务中去