微服务设计与解决方案.pdfVIP

微服务设计与解决方案

.1.1.1微服务设计与解决方案

微服务架构现在是谈到企业应用架构时必聊的话题，微服

务之所以火热也是因为相对之前的应用开发方式有很多优点，

如更灵活、更能适应现在需求快速变更的大环境。

本文将介绍微服务架构的演进、优缺点和微服务应用的设

计原则，然后着重介绍作为一个“微服务应用平台”需要提供哪

些能力、解决哪些问题才能更好的支撑企业应用架构。

微服务平台也是我目前正在参与的，还在研发过程中的平

台产品，平台是以SpringCloud为基础，结合了普元多年来对

企业应用的理解和产品的设计经验，逐步孵化的一个微服务应

用平台。

目录：

一、微服务架构演进过程

二、微服务架构的好处

三、微服务应用4个设计原则

四、微服务架构带来的问题

五、微服务平台的19个落地实践

六、总结瞻望

一、微服务架构演进过程

近年来我们大家都体会到了互联网、移动互联带来的好处，

作为IT从业者，在生活中时刻感受互联网好处的同时，在工

作中可能感受的却是来自自互联网的一些压力，那就是我们传

统企业的IT建设也是迫切需要转型，需要面向外部客户，我

们也需要应对外部环境的快速变化、需要快速创新，那么我们

的IT架构也需要向互联网企业研究作出相应的改进，来支撑

企业的数字化转型。

我们再看一下使用架构的演进进程，回想一下微服务架构

是如何一步一步进化发生的，最早是使用是单块架构，后来为

了具有肯定的扩展和可靠性，就有了垂直架构，也就是加了个

负载平衡，接下来是前几年比较火的SOA，主要讲了使用系

统之间如何集成和互通，而到现在的微服务架构则是进一步在

探讨一个使用系统该如何设计才能够更好的开发、管理更加灵

动高效。

微服务架构的基本思想就是“围绕业务领域组件来创建使

用，让使用可以自力的开发、管理和加速”。

二、微服务架构的好处

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

是每个微服务组件都是简单灵动的，能够自力摆设。不再

像以前一样，应

用需要一个庞大的应用服务器来支撑。

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

靠。

微服务之间是松耦合的，微服务内部是高内聚的，每个微

服务很容易按需

扩展。

微服务架构与语言工具无关，自由选择合适的语言和工具，

高效的完成业

务方针即可。

看到这里，大家会觉得微服务架构挺不错，然而还会有一

些疑问，什么样的使用算是一个微服务架构的使用?该怎样设

计一个微服务架构的使用?那我们来一起看看我们举荐的微服

务使用的设计原则。

三、微服务应用4个设计原则

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

AKF拆分原则

前后端分离

无状态服务

Restful通信风格

1.AKF拆分原则

AKF扩展立方体(参考《XXX》)，是一个叫AKF的公司

的技术专家抽象总结的使用扩展的三个维度。理论上按照这三

个扩展模式，可以将一个单系统统，进行无限扩展。

X轴：指的是水平复制，很好理解，就是讲单体系统多运

行几个实例，做个集群加负载均衡的模式。

Z轴：是基于类似的数据分区，比如一个互联网打车应用

突然或了，用户量激增，集群模式撑不住了，那就按照用户请

求的地区进行数据分区，北京、上海、四川等多建几个集群。

Y轴：就是我们所说的微服务的拆分模式，就是基于不同

的业务拆分。场景说明：比如打车应用，一个集群撑不住时，

分了多个集群，后来用户激增还是不够用，经过分析发现是乘

客和车主访问量很大，就将打车应用拆成了三个乘客服务、车

主服务、支付服务。三个服务的业务特点各不相同，独立维护，

各自都可以再次按需扩展。

2.前后端分离

前后端分离原则，简单来讲就是前端和后端的代码分离也

就是技术上做分离，我们推荐的模式是最好直接采用物理分离

的方式部署，进一步促使进行更彻底的分离。不要继续以前的

服务端模板技术，比如JSP，把JavaJSHTMLCSS都堆到一

个页面里，稍复杂的页面就无法维护。这种分离模式的方式有

几个