顾名思义，微服务要从两个方面来理解，一个是“微”，一个是“服务”。体型小到一定程度才能叫“微”，这个程度是什么呢？一个身高 1 米 6，体重 90 斤的 MM，我们说她苗条。微服务也一样，根据亚马逊 CEO Bezos 给出的有趣定义，单个微服务的设计、开发、测试和运维的所有人加在一起吃饭，只需要两个批萨就够了，这是就是著名的 two pizza team rule。 具备什么样的能力才能算是“服务”？这个话题很大，我这里按照自己的片面理解总结一下，所谓服务就一定会区别于系统的功能，服务是一个或者一组相对的较小且独立的功能单元，是用户可以感知的功能最小集，比如：购物车，订单，信用卡结算等都可以作为单个服务独立提供。 这个理解显然不够深刻，为了进一步理解为什么微服务在近两年业界迅速窜红，理解为什么微服务会被认为是 IT 软件架构的未来方向，就要理解为什么我们需要微服务？它能给企业带来什么价值。传统企业的 IT 软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性差，可靠性不高，维护成本高。后来有了一个叫 SOA 的软件架构专门针对这些问题给出了一套解决方案，很多企业也因此将自身IT系统迁移到 SOA 架构上。 但是，由于 SOA 早期均使用了总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间。最终 SOA 开起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。 微服务，从本质意义上看，还是 SOA 架构。但内涵有所不同，微服务并不绑定某种特殊的技术，在一个微服务的系统中，可以有 Java 编写的服务，也可以有 Python 编写的服务，他们是靠Restful 架构风格统一成一个系统的。 最粗浅的理解就是将微服务之间的交互看作是各种字符串的传递，各种语言都可以很好的处理字符串，所以微服务本身与具体技术实现无关，扩展性强。另一个不同是微服务架构本身很轻，底层也有类似于 SOA 的总线，不过非常轻薄，现在看到的就两种方式：MQ 和 HTTP，而 HTTP 都不能完全等同于总线，而仅仅是个信息通道。 所以，基于这种简单的的协议规范，无论是兼容老旧系统，还是上线新业务，都可以随着时代的步伐，滚动升级。比如：你去年还在使用.NET技术，今年就可以平滑的过度到 Go 了，而且系统已有服务不用改动。所以微服务架构，既保护用户已有投资，又很容易向新技术演进。 人月不是银弹，微服务更不是银弹，好像软件微服务化了，软件系统就能够应对各种问题了。其实微服务的水面下藏着巨大的冰山。下面是微服务提供的能力，以及背后需要付出的代价。
综上所述，微服务关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的“统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略，统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。 这些系统性的功能也需要有一些服务来提供，这些服务不会直接呈现给最终用户，也就是微服务系统冰山下面的部分，我们可以简称它为微服务系统的“底座”。所有的微服务都像一个 APP，插在这个底座的上面，享受这个底座提供的系统能力比如：元数据存放、灰度发布、蓝绿部署等等。
以下功能不是最小集的一部分，但也属于底座功能：
微服务的底座是不是必须的？ 是的，基本上是必须的。你可以不用代码实现一个资源管理服务，可以手工用 Excel 管理你的所有机器资源，但是不代表微服务系统没有这个功能，只不过这个功能是人工实现的。再举个例子，日志系统如果只是简单的打印文件，那么多个微服务的日志就需要手工收集，人工分类和筛选。所以，微服务的底座最小集一定会存在，问题是看怎样实现它。 这里仅仅是总结了对微服务系统的基本理解，而实现这个架构有很多技术，这里不进行详细展开。实践方面，推荐王磊的《微服务架构与实践》，他描述了使用 Ruby 相关的技术实现了一整套微服务系统，特别是书中后面的实践部分讲解了如何将已有的系统演化为微服务架构，是很好的参考和指导材料。 是不是所有软件都能做微服务？ 这个命题有些微妙，也很难说清楚，回答这个命题本身就是一种挑战，可能最终也没有正确答案。不过，我还是把我自己的理解写在这里，让大家去拍砖。在我这里，答案是否定的。我只需举出一个反例，比如：存储系统，其架构是传统的分层架构，每一层都使用下面一层的服务，并为上一层提供服务。虽然可以将这种架构调整为基于服务的架构，但没办法做成微服务。 区别在哪里呢？核心的区别在于独立性上，微服务大多是可以独立的运行和使用的，而存储这种非常底层和基础的系统，每层部件都不能单独被使用，比如：Pool管理、CHUNK管理、VOL管理、NFS文件系统，这些功能都无法离开另外一些功能而独立运行，要对外提供可用的存储功能，一大堆功能必须一起上。这种系统做到极致，最多也就能够使其部件可以独立的部署和升级，俗称打热补丁。 这也就是为什么这种底层传统系统架构通常是单块架构的原因。由于单块架构的各个部分调用关系紧密，做成微服务后系统集成成本会大大增加，不仅如此，这样的架构做成微服务并不能提高交付效率，因为各个部分根本就无法独立的运行和测试。 什么样的软件做成微服务？
StuQ特别邀请迅雷技术总监刘俊强老师设计推出《给我做一个Java微服务实战项目》精品课程，整个课程将以 eMall 示例项目为贯穿（专门为该课程编写的示例 在线商城项目），以架构设计历史简述为始，结合常用技术框架及工具帮助学员快速上手实现第一个微服务，再通过微服务实践过程中需要注意的数据模型、服务间通信等来进行多个微服务的设计实践，最后从测试、部署的角度来叙述在微服务最后上线及维护的相关事宜。 课程价格：原价1699元，前30名优惠价格1599元 （后台回复“彩蛋”享受更多折扣惊喜） 开课时间：2017年2月15日 课程周期：共计 8 周课程，每周 1 小时，每周四21:00-22:00 报名方式：PC端输入课程网址：http://www.stuq.org/course/detail/1160 或者扫描下方二维码进入课程详情页面，点击【立刻购买】报名 报名成功后点击【开始学习】填写邮箱及QQ等信息，一定！一定！一定要申请加入QQ学员群喔（重要的事情说三遍），会有 StuQ 工作人员在学员群内发放上课方式。 想要人工咨询课程相关信息可以扫描下方二维码进入
点击“阅读原文”了解StuQ更多课程 |
|
声明：文章版权归原作者所有 部分文章转自互联网 如有侵权请联系
[邮箱地址] 删除
|
注册
登录
