数据
08年底上线，最初只是个PC端个人网站。
目前：APP下载量超过1.3亿，注册用户超过3000万，日活180万+，UGC上传菜谱量 80万+，总作品量600万+。
菜谱+社区+电商的三大产品线。
面临问题
- 人数多了以后，团队分工协作难
- 单体架构强耦合，无法根据业务功能作伸缩。
- 阻碍技术更新换代，老系统牵一发动全身。
- 业务监控难做。（评：这个跟架构关系不大吧，反而我觉得微服务化后，监控更加不好做了呢。）
微服务架构模式：
微服务架构图.png
聚合器可以是简单的web页面，也可以是组合服务。组合服务也有自己的缓存和数据库。
聚合器可以沿X轴和Y轴扩展。
准备工作
- 工具化、自动化。测试部署提前准备好自动化工具。
- 新的架构设计原则。
原单体架构下更多关注功能、性能等维度。
微服务的设计原则：
- MVP（最小可用产品）
- 面上失败的设计（拥抱失败、而不是阻止失败）
- 宽进严出（对请求宽进严出，对外的响应要严格规范化）
- 宁花机器一分，不花人工一秒（自动与自助、复杂重复的事情交给平台工具去做，让程序员去做更有价值的事情）
- 一切皆资源
- 团队变革，专人专项。
改造遵循的原则
理论：基于业务进行拆分、采用自动化文化、去中心化、服务独立部署、服务完全自治、隔离失败、渐进式拆分、避免大规模改造原有代码。
实践：
- 先分离数据库、后分离服务。
- 替换代替打补丁。
老的系统不好改动的，就不管了。用新的微服务逐渐替代。 - 建立统一的日志规范。
便于后续的日志聚合检索，整体视角分析、监控、查看系统。
logstash+ElasticSearch+kibana 实现了服务的类即时监控。
改造平滑迁移
- 工具很重要，自动化测试、部署工具。配套的日志分析监控系统。
- 小步快跑，不重要的模块做试点。
豆果美食架构图.png
微服务优缺点
优点：
- 明确的模块边界。
- 独立部署。自治的，某个模块出问题不会导致整个系统崩溃。
- 技术多样性。可以开发语言异构。
- 团队扁平化有帮助。
缺点： - 开发维护难。
- 强一致性难度大。
- 不建议中小项目使用。
转自：https://comet-project.gitbooks.io/cto-tech-manual/content/chapter2/zhangzhijian.html
网友评论