微服务架构的4大设计原则和1个平台实践

本文转载自微信公众号EAWorld 微服务架构现在是谈到企业应用架构时必聊的话题，微服务之所以火热也是因为相对之前的应用开发方式有很多优点，如更灵活、更能适应现在需求快速变更的大环境。 本文介绍微服务架构的演进、优缺点和微服务应用的设计原则，然后着重介绍作为一个“微服务应用平台”需要提供哪些能力、解决哪些问题才能更好地支撑企业应用架构。 微服务平台也是我目前正在参与的，还在研发过程中的平台产品，平台是以Spring Cloud为基础，结合了普元多年来对企业应用的理解和产品的设计经验，逐步孵化的一个微服务应用平台。 目录： 一、微服务架构演进过程 二、微服务架构的好处 三、微服务应用4个设计原则 四、微服务架构带来的问题 五、微服务平台的19个落地实践 六、总结展望 一、微服务架构演进过程 近年来我们大家都体会到了互联网、移动互联带来的好处，作为IT从业者，在生活中时刻感受互联网好处的同时，在工作中可能感受的却是来自互联网的一些压力，那就是我们传统企业的IT建设也是迫切需要转型，需要面向外部客户，我们也需要应对外部环境的快速变化、需求快速创新，那么我们的IT架构也需要向互联网企业学习做出相应的改进，来支撑企业的数字化转型。 我们再看一下应用架构的演进过程，回忆一下微服务架构是如何一步一步进化产生的，最早应用是单体架构，后来为了具备一定的扩展和可靠性，就有了垂直架构，也就是加了个负载均衡，接下来是前几年比较火的SOA，主要讲了应用系统之间如何集成和互通，而到现在的微服务架构则是进一步在探讨一个应用系统该如何设计才能够更好地开发、更加灵活高效地管理。 微服务架构的基本思想就是“围绕业务领域组件来创建应用，让应用可以独立地开发、管理和加速”。 二、微服务架构的好处 我们总结了四个方面的优点，分别如下： 每个微服务组件都是简单灵活的，能够独立部署。不再像以前一样，应用需要一个庞大的应用服务器来支撑。 可以由一个小团队负责，更专注专业，相应地也就更高效可靠。 微服务之间是松耦合的，微服务内部是高内聚的，每个微服务很容易按需扩展。 微服务架构与语言工具无关，自由选择合适的语言和工具，高效地完成业务目标即可。 看到这里，大家会觉得微服务架构挺不错，然而还会有一些疑问，什么样的应用算是一个微服务架构的应用？该怎样设计一个微服务架构的应用？那我们一起来看看我们推荐的微服务应用的设计原则。 三、微服务应用4个设计原则 我们总结了四个原则推荐给大家： AKF拆分原则 前后端分离 无状态服务 Restful通信风格 1.AKF拆分原则 AKF扩展立方体（参考《The Art of Scalability》），是AKF公司的技术专家抽象总结出的应用扩展的三个维度。理论上按照这三个扩展模式，可以将一个单体系统，进行无限扩展。 X 轴 ：指的是水平复制，很好理解，就是讲单体系统多运行几个实例，做个集群加负载均衡的模式。 Z 轴 ：是基于类似的数据分区，比如一个互联网打车应用突然火了，用户量激增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。 Y 轴 ：就是我们所说的微服务的拆分模式，就是基于不同的业务拆分。 场景说明：比如打车应用，一个集群撑不住时，分了多个集群，后来用户激增还是不够用，经过分析发现是乘客和车主访问量很大，就将打车应用拆成了三个：乘客服务、车主服务、支付服务。三个服务的业务特点各不相同，独立维护，各自都可以再次按需扩展。 2.前后端分离 前后端分离原则，简单来讲就是前端和后端的代码分离，也就是技术上做分离，我们推荐的模式是最好直接采用物理分离的方式部署，进一步进行更彻底的分离。不要继续以前的服务端模板技术，比如JSP