我终于搞懂了微服务，真的太不容易了~

一、业务背景

1.1 产品现状

1、各产品系统独立开发，代码复用率低，系统之间互相调用，耦合严重，系统解耦独立部署困难。
2、传统的单体架构，规模越来越大也越来越笨重；当新功能的开发、功能的重构变得不再敏捷可控；测试者的回归测试边界难以琢磨；系统的上线部署也变的艰难
3、高并发访问下无法提供可靠性服务
4、持续集成、持续部署、持续交付等工程效率化工具严重缺失
5、监控系统、日志分析等系统稳定性工具严重缺失
以上种种情况，都让我们应对需求的变化而变得迟钝。

1.2 业务需求

架构肯定是为业务需求而生的，先来看看我们面对的业务需求及其特点。平台最主要满足两大类业务需求：面向餐饮企业在餐饮新零售下的经营和运营需求和面向产品及运营团队。
具体来看：
1、餐饮新零售下的餐饮企业经营和运营的痛点

• 如何提升营销能力和管理会员，以更低的成本为餐饮企业带来更多利润

• 如何对数据进行深度挖掘和分析，助力决策者进行运营决策

• 如何掌握实时数据，让决策者及时了解餐厅运营情况

2、面向产品及运营团队

• 主要是提升产品控制能力，促进整体系统的良好运转

因此开发SAAS服务的产品迫在眉睫，需要满足快速开发、灵活升级、高性能、高可用、高稳定、简化运维等更高的需求。

这一步的转型，不是"快"与"慢"，而是"生"与"死"。

二、微服务概念

专注于单一责任与功能独立运行的服务，模组化方式组合出大型应用。

2.1 特点

• 集中式架构：单体无分散

• 分布式架构：分散压力

• 微服务架构：分散能力

2.2 微服务架构优势

• 每个微服务组件都是简单灵活的，能够独立部署。不再像单体应用时代，应用需要一个庞大的应用服务器来支撑。

• 可以由一个小团队负责更专注专业，相应的也就更高效可靠。

• 微服务之间是松耦合的，微服务内部是高内聚的，每个微服务很容易按需扩展。

三、微服务技术选型和微服务的问题

3.1 技术选型

3.1.1 技术矩阵结论

• Netflix提供了比较全面的解决方案

• Spring Cloud对于Netflix的封装比较全面

• Spring Cloud基于Spring Boot，团队有基础

• Spring Cloud提供了Control Bus能够帮助实现监控埋点

• 业务应用部署在阿里云，Spring Cloud对12 Factors以及Cloud-Native的支持，有利于在云环境下使用

3.1.2 团队期望

• 首先支持Rest

• 团队技术栈和实例比较单薄，希望对新的技术平滑的学习曲线和能够Hold住

• 小团队，希望能够有一个比较全面的解决方案

• 目前团队主要采用Spring Cloud + Spring Boot的方式实现服务化

3.2 微服务带来的问题

• 依赖服务变更很难跟踪，其他团队的服务接口文档过期怎么办？依赖的服务没有准备好，如何验证我开发的功能。

• 部分模块重复构建，跨团队、跨系统、跨语言会有很多的重复建设。

• 微服务放大了分布式架构的系列问题&#