第1讲 什么是微服务架构
Martin flower在博文中给出的微服务的特点如下：
一组小的服务
独立的进程
轻量级部署
基于业务能力（用户服务、登录服务、商品服务）
独立部署（每个团队维护自己的服务，团队之间不需要协调）
无集中式管理
Netflix前架构师给出的微服务的定义：
Loosely coupled（松散耦合，服务之间非强依赖）
Service Oriented architecture（本质上还是SOA）
with bounded context（服务之间有边界，可独立演化）
第2讲 微服务的利弊
讲了微服务的利和弊
微服务的利
强模块化边界
可独立部署
技术多样性
微服务的弊
分布式复杂性
相对于单体应用，现在，细分成很多服务，开发人员无法理解整个系统是如何工作的。
最终一致性
运维复杂性
测试复杂性
对于单体应用，直接测试整个系统功能就可以了；微服务后，各个系统分散在各个团队，需要多个团队联调做
集成测试。
（我自己的理解：
关于微服务的利与弊，其实就是把一个系统细分为多个服务后，系统可看做整体，每个微服务可看做部分。好处是容易把控每个微服务自己，各个团队负责自己的服务就好了，坏处就是对系统整体的把握上会出现一些不便，比如对系统整理的理解、对系统的测试等）
思考以下问题：
运维团队，面对微服务的时候，应该采用什么样的手段来应对运维复杂性？
第3讲 康威法则
康威法则：系统的架构等价于组织的架构。
（我自己的理解就是：
如果系统是单体应用，那么应该是一个团队负责。
如果系统微服务化以后，比如分为服务A，B，C，那么组织架构上，也应当划分为A，B，C三个团队，每个团队可独立迭代。
)
思考以下问题：
作为架构师， 为什么不仅仅要做技术架构，也要了解组织架构？
第4讲 企业应该什么时候引入微服务
单体优先原则：不宜过早引入微服务，因为系统初期对系统的未来发展无法预知，过早引入微服务风险较高。
（我自己的理解：
不要在系统初期直接上微服务架构，而是在系统演变过程中逐渐引入）
抛出的问题：
架构是设计出来的还是演进出来的？
第5讲 什么样的组织结构更适合微服务
传统的组织架构：
一个产品需要产品团队、用户体验团队、研发专家团队、测试专家团队、DBA专家团队、运维专家团队等。
微服务组织架构：
每个微服务团队end-end ownership，从开发到测试到运维等，统统自己负责，形成闭环
Archite--->Design--->Develo--->Reivew--->Test--->Deploy--->Run--->Support
思考以下问题：
Netflix前总架构师说了一句话，微服务架构本质上是组织架构的重组，你如何理解这句话？
第6讲 如何理解阿里巴巴提出的微服务中台战略
大中台，小前台。 强化“技术中台+业务中台”，中台肥沃，在这上面的业务生态才会更繁荣。业务应用更小更灵活，迭代能力变强，按照市场变化不断演化新应用出来。
思考以下问题：
大中台，小前台战略。每个架构师怎样在每个公司内部实践。
第7讲 如何给出一个清晰简洁的服务分层方式