LMD 置顶2018-01-26关于《微服务架构核心20讲》课程讲义（PDF 文件），学员可复制下面链接到浏览器下载获取。 http://t.cn/RQs9iTw 34
2018-01-18服务拆分后成微服务后，部署必然也是分离部署。让运维人工来支持发布、扩容或者缩容、监控机器运行指标，将变得极不现实。
这个时候，也就必然要求自动化非常高的运维，以支持微服务系统的稳定运行。
尽可能把能自动化的工作交由机器来负责，降低人工投入；提升工作效率，也降低人工犯错的概率。 23
2018-01-26对于多语言协同构建微服务，理论可行。但是如果没有一个完整的技术栈与管理栈，盲目的采用微服务多语言协同开发，绝对是一场噩梦，建议采用有着成熟体系与技术栈的spring cloud来实现微服务框架体系。阿里的dubbo根本算不上一个完整的技术栈，dubbo为了速度做了太多妥协。 10- 2018-03-15借助docker，以及在paas平台加入持续集成、持续交付的功能，可以大大简化微服务运维成本，很多东西都可以实现自动化，我们公司就是这么做的
作者回复: 嗯，大规模微服务需要paas平台支撑。
5 
2018-03-21容器化部署可以提高运维效率，节省成本作者回复: 是方向，但对研发运维要求也高，需要一定研发定制能力，devops文化等
4
2018-07-09杨老师，关于数据一致性的问题有点思考，每个微服务模块只保存自己的业务相关数据，想获取其他数据，只需通过调用其他模块的微服务不就可以了吗？为什么非要每个模块保存一份然后进行同步？业界的实践情况到底什么样的？作者回复: 比方很多后台批处理服务，定期要对批量数据进行处理，这时数据量很大，不可能弄个大调用去数据源取数据，只能复制一份并定期或实时同步变更
3
2018-04-13保证数据一致性的解决方案有什么思路呢？作者回复: 有一些强一致性技术手段，这边回复难展开，会另开专题讲，最终一致性是业界一般性实践和推荐思路。
2
2018-01-08不错 2
2019-01-26微服务第二章：微服务的利与弊，便利的地方包括 1.可以模块化 2.独立部署3.开发的多样性 ，弊端有1.分布式的复杂性 2.数据不一致性 3.运维的复杂性 4.测试的复杂性，应该根据不同的需求和场景 来使用 微服务。
回答老师的问题：怎么运维 微服务，根据不同的 模块 分别 进行不同情形的维护，还可以 分别 定制 自动化维护的工具。 1
2018-11-13面对单体应用，运维的挑战在于整体的灰度发布，以及线上出现问题时的整体回滚。
面对微服务应用，运维不仅需要解决单个服务的灰度发布和回滚，还需要考虑微服务间的相互影响。一个上游服务的不可用导致所有下游服务不可用怎么办。运维需要识别出服务间的上下游关系，对于上游服务可能产生的对下游服务的影响保持警觉。
由于服务众多，关系复杂，运维过程更加依赖于自动化。要努力实现自动化集成测试、自动部署、自动回滚、问题链路自动发现，最终实现持续集成。 1
2019-04-21我有个疑问 比如自动化运维部署 也是机器或依次或分批进行部署 这时候是用户无感知 那比如我加字段 加业务逻辑 是不是就没有一个很好地切入点 去洗数据做兼容呢作者回复: 如果是不兼容的升级部署，这个时候就不能用简单的分批灰度发布，需要做特殊处理，先做严格内部或者beta用户测试，然后再考虑如蓝绿部署，一把切换，有问题一把回退。
一般尽量考虑兼容升级，通过代码开关控制新业务逻辑的打开或者关闭（可以和配置中心如Apollo配合），这个称为开关驱动开发(Feature Flag Driven Development)这样风险更小，而不是单纯靠运维部署。
2018-12-26初学者问个初级问题，微服务的物理载体是啥，都是一堆api么？
2018-12-22感觉来晚了，课程很棒
2018-11-11双十一果断定制，开始跟着杨老师学微服务😊😊作者回复: 多谢支持🌹
2018-10-09早就买了 今天才抽空来看看视频 杨波老师太牛了，受益颇深，之前一直在对微服务有些模棱两可的理解。作者回复: 谢谢支持🌹
- 2018-08-25老师，您好！
视频中提到 A 团队有订单数据，而 B 团队也有订单数据？不是很明白，上一节提到微服务的特点，包含了非集中式的数据源，如果 A 团队负责订单服务，B 团队可以调用 A 团队的服务获取订单数据呀？为什么需要多冗余一份呢？作者回复: A和B团队都有订单数据的概念，但格式和用途是不一样的，比方说A团队维护电商线上web订单数据，B团队维线下ERP系统订单数据（同时包括线上web和线下门店），发货以线下ERP系统为准，那么线上订单就要定期同步到线下。
2018-05-06对于一个运维团队而言，为了适应微服务 能够做的事情有以下几点：
1 为了解决分布式服务的问题 首先要 一个比较强大的服务管理系统 这个系统最好与cmdb打通,这样每个服务大概有哪些机器 每个机器又有哪些服务是可以一目了然的
2 为了解决数据同步的问题 运维提前构建一套标准化的 队列服务是非常有必要的 这样每个服务在发生对固定数据源的变更的时候 通过预先定义的方式 传递给队列 而在发生一些队列不可达 或者是消息丢失的时候 有一套默认的 或者说有效的 防止机制 从而保证最终的数据一致性
3 再回到服务的部署本身 一套统一的发布系统也是非常有必要的 如果这套发布系统能够与对应的测试用例或持续集成结合 就能够解决测试的问题作者回复: 你提到服务治理，消息中间件服务，统一发布体系，都是微服务架构体系范筹
2018-04-30请教大牛：独立部署是逻辑还是物理概念?比如一个数据报送分析系统，是按照功能拆分为：数据报送模块、数据分析模块、机构管理模块、系统管理模块，然后每个模块部署在一个容器里吗?怎么组合成一个监测系统?还是按照系统架构划分为：前端客户端web应用、后端服务器端数据处理系统，分别部署在容器里呢？如果前端客户端用户登录的web应用，用GO语言开发；数据分析系统套用现成的商业分析系统BI@report，是用JAVA语言开发的；然后部署在容器里，放在服务器上跑。可以实现吗？这算是基于微服务架构设计的系统吗？困惑中。谢谢！菜鸟级作者回复: 具体要不要把服务分那么细，每个都独立部署在独立的虚拟机或者容器中，要看你的业务复杂性和规模，还有团队规模，一般公司越大分得越细，否则会有效率问题。小规模的话，搞那么多服务反而增加复杂性，做好基本的模块化就好了。
2018-02-19棒棒哒作者回复: 谢支持🌹