微服务， 强调一个“微”字，体现的是细粒度的高内聚、低耦合
它很小，专注于做好一件事
把因相同原因而变化的东西聚合在一起，把因不同原因而变化的东西分离开来
一个微服务应该在两个内可以重写
代码从你的笔记本到生产环境要多久
微服务需要隔离变化， 这个变化可能是由我们程序员比较关注的代码的业务边界或者说限界上下文引起，比如商品管理和营销活动设置；也可能是由于产品需求变化的速度不一致引起，比如商品基本信息的管理和商品时效信息（退改规则、费用说明等）调整的频率就差距很大， 产品经理会经常调整时效信息的文案和录入规范； 或者是为了匹配部门的组织架构 等等。
隔离了变化后
- 技术异构性得以支持， 每个服务可以选用最适合的技术栈去实现
- 整体可用性的提升， 这个类似分布式系统带来的部分不可用不影响整体主流程一样的优势
- 部署的风险降低， 想象一下 修改一个小bug而不得不发布整个庞大的项目
- "微" 之后， 替换原来的实现方式（技术栈、重构）风险就会小很多，两个星期内能重写就太棒了
...
不过，既然是服务，就必须面对服务类架构需要解决的问题
- 保证api的技术无关性，不使用平台绑定的接口实现， 如提供的服务java能调用 .net能调用 python及其他也能调用
- 协议的选择， rpc 还是 rest， json 还是其他
- 如何方便消费者使用 等
其他可以参考下 soa服务技术的设计原则
微服务要快速上线， 需要持续集成，需要持续交付，需要测试来保证质量
那么上线后是不是就没事了？ 线上出了问题如何排查？ 你还得监控
微服务感觉散落一地的玻璃珠一样， 需要监控小的服务，然后串起来看整体
或许你要跟踪一长串调用链上每个节点的响应时长，还需要一个关联标记来串起这个调用链看看调用节点之间的联系
代码从你的笔记本到生产环境要多久? 要清晰限界上下文，隔离变化原因，要可持续集成，持续交付，保证速度的同时也要保证质量...
其实，微服务不正是我们学习设计模式时和面向对象编程时强调的各种原则的体现么
扩展资料：
CAP定理
BASE 模型
什么叫 REST，以及什么是 RESTful
如何度量应用的RESTful成熟度
rest apis must be hypertext-driven
论文 Representational State Transfer (REST)
微服务架构的理论基础 - 康威定律
