微服务设计原则

微服务架构演进过程

近年来我们大家都体会到了互联网、移动互联带来的好处，作为 IT 从业者，在生活中时刻感受互联网好处的同时，在工作中可能感受的却是来自自互联网的一些压力，那就是我们传统企业的 IT 建设也是迫切需要转型，需要面向外部客户，我们也需要应对外部环境的快速变化、需要快速创新，那么我们的 IT 架构也需要向互联网企业学习作出相应的改进，来支撑企业的数字化转型。

我们再看一下应用架构的演进过程，回忆一下微服务架构是如何一步一步进化产生的，最早是应用是单块架构，后来为了具备一定的扩展和可靠性，就有了垂直架构，也就是加了个负载均衡，接下来是前几年比较火的 SOA，主要讲了应用系统之间如何集成和互通，而到现在的微服务架构则是进一步在探讨一个应用系统该如何设计才能够更好的开发、管理更加灵活高效。

微服务架构的基本思想就是 “围绕业务领域组件来创建应用，让应用可以独立的开发、管理和加速”。

微服务架构的好处

我们总结了四个方面的优点，分别如下：

• 是每个微服务组件都是简单灵活的，能够独立部署。不再像以前一样，应用需要一个庞大的应用服务器来支撑。
• 可以由一个小团队负责更专注专业，相应的也就更高效可靠。
• 微服务之间是松耦合的，微服务内部是高内聚的，每个微服务很容易按需扩展。
• 微服务架构与语言工具无关，自由选择合适的语言和工具，高效的完成业务目标即可。

看到这里，大家会觉得微服务架构挺不错，然而还会有一些疑问，什么样的应用算是一个微服务架构的应用?该怎样设计一个微服务架构的应用?那我们来一起看看我们推荐的微服务应用的设计原则。

微服务应用4个设计原则

我们总结了四个原则推荐给大家：

• AKF 拆分原则
• 前后端分离
• 无状态服务
• Restful 通信风格

AKF拆分原则

AKF 扩展立方体(参考 《The Art of Scalability》)，是一个叫 AKF 的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，可以将一个单体系统，进行无限扩展。

• X 轴 ：指的是水平复制，很好理解，就是讲单体系统多运行几个实例，做个集群加负载均衡的模式。
• Z 轴 ：是基于类似的数据分区，比如一个互联网打车应用突然或了，用户量激增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。
• Y 轴 ：就是我们所说的微服务的拆分模式，就是基于不同的业务拆分。

场景说明：比如打车应用，一个集群撑不住时，分了多个集群，后来用户激增还是不够用，经过分析发现是乘客和车主访问量很大，就将打车应用拆成了三个乘客服务、车主服务、支付服务。三个服务的业务特点各不相同，独立维护，各自都可以再次按需扩展。

前后端分离

前后端分离原则，简单来讲就是前端和后端的代码分离也就是技术上做分离，我们推荐的模式是最好直接采用物理分离的方式部署，进一步促使进行更彻底的分离。不要继续以前的服务端模板技术，比如 JSP ，把 Java JS HTML CSS 都堆到一个页面里，稍复杂的页面就无法维护。这种分离模式的方式有几个好处：

• 前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果会更好。
• 分离模式下，前后端交互界面更加清晰，就剩下了接口和模型，后端的接口简洁明了，更容易维护。

前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支撑前端的 web UI 移动 App 等访问。

无状态服务

对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个 “状态” 数据的服务被称为有状态服务，反之称为无状态服务。

那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的 “有状态数据服务” 中。

场景说明：例如我们以前在本地内存中建立的数据缓存、Session 缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。

Restful通信风格

作为一个原则来讲本来应该是个 “无状态通信原则”，在这里我们直接推荐一个实践优选的 Restful 通信风格 ，因为他有很多好处：

• 无状态协议 HTTP，具备先天优势，扩展能力很强。例如需要安全加密是，有现成的成熟方案 HTTPS 可用。
• JSON 报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。
• 语言无关，各大热门语言都提供成熟的 Restful API 框架，相对其他的一些 RPC 框架生态更完善。

当然在有些特殊业务场景下，也需要采用其他的 RPC 框架，如 thrift、avro-rpc、grpc。但绝大多数情况下 Restful 就足够用了。

微服务架构带来的问题

做到了前面讲的四个原则，那么就可以说是构建了一个微服务应用，感觉上也不复杂。但实际上微服务也不是个万金油，也是有利有弊的，接下来我们来看看引入微服务架构后带来的问题有哪些。

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

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

微服务放大了分布式架构的系列问题，如分布式事务怎么处理?依赖服务不稳定怎么办?

运维复杂度陡增，如：部署物数量多、监控进程多导致整体运维复杂度提升。

上面这些问题我们应该都遇到过，并且也会有一些解决方案，比如提供文档管理、服务治理、服务模拟的工具和框架; 实现统一认证、统一配置、统一日志框架、分布式汇总分析; 采用全局事务方案、采用异步模拟同步;搭建持续集成平台、统一监控平台等等。

这些解决方案折腾到最后终于搞明白了，原来我们是需要一个微服务应用平台才能整体性的解决这些问题。