前言
微服务的起源是由 Peter Rodgers 博士于 2005 年度云端运算博览会提出的微 Web 服务 (Micro-Web-Service) 开始，2014年，Martin Fowler 与 James Lewis 共同提出了微服务的概念，定义了微服务是由以单一应用程式构成的小服务，自己拥有自己的行程与轻量化处理，服务依业务功能设计，以全自动的方式部署，与其他服务使用 HTTP API 通讯。同时服务会使用最小的规模的集中管理 (例如 Docker) 能力，服务可以用不同的程式语言与资料库等元件实作。（引用自维基百科）
微服务架构使得开发的速度更快，部署越来越自动化，服务和服务之间的隔离性高，整个系统的水平扩展能力非常强，但是同时也对运维、微服务管理、状态管理以及测试方面提出了更高的要求。
微服务架构的一些理念和原则网络上很多的文章都已经描述的很清楚了，本文想从另外一个不同的角度来尝试阐述一下微服务架构。要理解微服务，首先来看一下什么是服务。
什么是服务
生活中我们都会接触到服务，我们去餐馆吃饭是去享受餐馆给我们的服务，去银行办事是去享受银行的服务，所以服务是一种向外提供的对使用者来说有价值的东西。
服务有好坏之分。如果某家餐馆上菜快、菜味道非常好以及能够及时响应和满足顾客的需求，我们往往会说这家餐馆的服务好。如果到银行办事排队要排两个小时，然后真正办事的时候两分钟就好了，有时候可能因为证件没有准备好需要重新排队办理，那我们就会认为该银行的服务差，至少感觉不好。所以服务的好坏是由很多因素一起来决定的，另外在不同的领域里服务的好坏评价标准也是不一样的。
服务有大小之分。现实生活中的很多服务往往都是大颗粒的服务，如报团旅游，旅行社提供飞机、住宿、餐饮等一系列的服务。也有非常小颗粒的服务，如去便利店买一瓶水等。
大颗粒服务的优点是简化了消费者的工作，当然缺点也很明显：对于消费者来说跟这个大颗粒服务绑定了，大颗粒服务的是否可用完全决定了消费者是否可以享受这次服务，大颗粒服务的好坏也完全决定了消费者对于服务体验的好坏。还是拿报团旅游举两个例子来说明大颗粒服务对于服务可用性和体验好坏的影响：（1）大颗粒服务影响可用性例子：我们好不容易盼到几天假期，早早就报团准备出去放松下，但是突然在出发之前被告知因为没有合适的住宿此次旅游取消了，这时我们往往不会再去报另外的旅行团了，因为时间上来不及了。但是如果我们的飞机、住宿、餐饮等都是单独预定的服务，当被告知预定的住宿因为意外原因被取消时，我们也基本上不会取消这次旅行，而是会去另外想办法找替代住宿的地方。（2）大颗粒服务影响体验好坏例子：旅行社提供的一系列服务中如果住宿特别差，我们想把住宿替换了也会比较困难，住宿差也会让我们对旅行社的整体服务的评价比较低，因为我们会把这一系列服务当作一个整体来看待。但是如果是单独预定的，住宿特别差，我们替换起来也会非常方便，另外对于整体的服务体验来说影响也会较低。
小颗粒服务可以克服大颗粒服务的缺点，但是对于消费者来说会比较麻烦，因为涉及的服务多了，服务的调用和消费会比较复杂。例如我们如果自己不报团旅游的话，飞机、餐馆以及住宿等服务的预定和消费都需要我们自己管理。
图1:旅行社的大颗粒服务让顾客没有选择和替换的空间
对于软件领域来说，服务是某一软件实体对外提供的功能，有着对外提供服务的接口以及能够完成调用者的期望动作的能力。软件领域的服务也存在好坏和大小之分。那什么样的软件架构才能兼有大颗粒和小颗粒服务的优点呢？有一种思路是微服务+服务中台。微服务解决大颗粒服务的缺点，而服务中台则解决小颗粒服务的缺点。
微服务+服务中台
微服务+服务中台的设计思想如下图所示：
图2:微服务+服务中台设计思想
前台UI遵循以用户为中心的设计思想。以用户为中心的设计就是完全站在用户的角度来思考前台UI的设计，使用清晰合理的界面逻辑来帮助用户达成目标。前台UI应该尽可能的轻，这样才能够快速地去适配不同用户的不同需求。
后台微服务遵循以业务为中心的设计思想。以业务为中心的设计就是完全站在业务处理的角度来思考微服务的设计，需要考虑业务处理的各种场景，使用合理的设计达到微服务之间的隔离性高，扩展性好等目标。因为业务领域的东西不会经常变化，并且随着市场的发展对于服务的需求量可能会呈现指数级的增加，所以后台服务应该尽可能地保持稳定和维持很好的扩展性，这样整个微服务集群才能够向外稳定地提供服务。
服务中台遵循以用户为中心的流程来驱动微服务之间的协作的设计思想。服务中台起到协调前台UI和后台微服务之间的作用，针对不同用户的不同处理流程，可以驱动不同的微服务之间进行协作，从而满足不同的业务处理需求的目的。服务中台应该尽可能地强大，这样才能够应付用户的各种不同的业务处理需求。
下图的图还是以用户报团旅游为例子来说明微服务+服务中台的思想；
图3:旅行社以用户为中心来驱动来选择微服务
网友评论