- J3 - 白起
- 技术 # 笔记 # 小白学微服务
近几年，不管是在学习还是在工作，都经常会见到“微服务”一词。那么什么是微服务呢！为什么近几年它的热度一直居高不下呢！带着这两个疑问来往下看。
我们要聊微服务的话，就不得不说系统架构设计的三个阶段了
- 单体集中式架构
- 分布式架构
- 微服务架构
一、单体集中式架构
把所有的功能、模块都集中到一个项目中，部署在一台服务器上，从而对外提供服务（单体架构、单体服务、单体应用）。
直白一点：就是只有一个项目，只有一个war。
这样做的好处就是在系统规模比较小的情况下工作情况良好，而且部署也是相对简单；但是随着系统规模的扩大，它暴露出来的问题也越来越多，主要有以下几点：
- 复杂性逐渐变高
比如有的项目有几十万行代码，各个模块之间区别比较模糊，逻辑比较混乱，代码越多复杂性越高，越难解决遇到的问题。 - 技术债务逐渐上升
公司的人员流动是再正常不过的事情，有的员工在离职之前，疏于代码质量的自我管束，导致留下来很多坑，由于单体项目代码量庞大的惊人，留下的坑很难被发觉，这就给新来的员工带来很大的烦恼，人员流动越大所留下的坑越多，也就是所谓的技术债务越来越多。 - 部署速度逐渐变慢
这个就很好理解了，单体架构模块非常多，代码量非常庞大，导致部署项目所花费的时间越来越多，曾经有的项目启动就要一二十分钟，这是多么恐怖的事情啊，启动几次项目一天的时间就过去了，留给开发者开发的时间就非常少了。 - 碍技术创新
比如以前的某个项目使用struts2写的，由于各个模块之间有着千丝万缕的联系，代码量大，逻辑不够清楚，如果现在想用spring mvc来重构这个项目将是非常困难的，付出的成本将非常大，所以更多的时候公司不得不硬着头皮继续使用老的struts架构，这就阻碍了技术的创新。 - 无法按需伸缩
比如说电影模块是CPU密集型的模块，而订单模块是IO密集型的模块，假如我们要提升订单模块的性能，比如加大内存、增加硬盘，但是由于所有的模块都在一个架构下，因此我们在扩展订单模块的性能时不得不考虑其它模块的因素，因为我们不能因为扩展某个模块的性能而损害其它模块的性能，从而无法按需进行伸缩。
这些缺点加起来就不得不让我们去试着优化这种架构了，那就是将单体系统按功能按模块拆分（分布式微服务架构）。
二、分布式架构
把所有的功能、模块拆分成不同的子项目，部署在多台不同的服务器上，这些子项目相互协作共同对外提供服务。
直白一点：就是有很多项目，有很多war包，这些项目相互协作完成需要的功能，不是一个war能完成的，一个war包完成不了。
分布式系统可以解决传统单体是架构的诸多问题，主要优势有以下几个点：
- 增大系统容量
垂直或是水平拆分业务系统，让其变成一个分布式的架构 - 加强系统可用
通过分布式架构来冗余系统以消除单点故障，从而提高系统的可用性 - 模块重用度高
- 软件服务模块被拆分，开发和发布速度可以并行而变得更快
- 系统扩展性更高
- 团队协作流程改善
他能很好的解决大规模并发情况下的流量处理问题，因为分布式架构是将多个功能分散部署到不同的服务器上这样就可以通过集群技术把大规模并发请求的负载分散到不同的机器上，以减轻单个系统承受的压力（负载均衡）。
如果分布式系统用到了集群技术的话，还可以大大的提高系统的可用性，当一个集群部署的分布式系统中有一个系统宕机出现问题时则会有其他相同功能的系统来代替它进行工作，从而保证系统的高可用性。
那么有了分布式系统，为什么还会出现微服务系统架构呢！
三、微服务架构
微服务一词源于2012年，于2014年因 Martin Fowler（马丁.福勒）的名为 Microservices 的博文而广为流行， 可以在他的官方博客上找到这篇文章：
http://martinfowler.com/articles/microservices.html
中文翻译版本（本人英文不好，嘿！这篇翻译版强烈推荐）：
http://blog.cuicc.com/blog/2015/07/22/microservices/#
简单地说， 微服务是系统架构上的一种设计风格， 它的主旨是将一个原本独立的系统拆分成多个小型服务，这些小型服务都在各自独立的进程中运行，服务之间通过基于 HTTP（dubbo -->dubbo协议 ） 的 RESTful API (controller --> 调用 congtroller）进行通信协作。
被拆分后的每一个小型服务都专注于完成系统中的某一项业务功能，职责单一， 并且每个服务都是一个独立的项目，可以进行独立的测试、开发和部署等。
由于各个独立的服务之间使用的是基于 HTTP 的 JSON 作为数据通信协作的基础，所以这些微服务也可以使用不同的语言来开发。
微服务的经典演变图，出自马丁.福勒的博文。
微服务架构在设计上遵循以下几个原则：
- 单一职责原则每个微服务只需要实现自己的业务逻辑就可以了，比如订单管理模块，它只需要处理订单的业务逻辑就可以了，其它的不必考虑。
- 服务自治原则每个微服务从开发、测试、运维等都是独立的，包括存储的数据库也都是独立的，自己就有一套完整的流程，我们完全可以把它当成一个项目来对待。不必依赖于其它模块。
- 轻量级通信原则首先是通信的语言非常的轻量，第二，该通信方式需要是跨语言、跨平台的，之所以要跨平台、跨语言就是为了让每个微服务都有足够的独立性，可以不受技术的钳制。
- 接口明确原则由于微服务之间可能存在着调用关系，为了尽量避免以后由于某个微服务的接口变化而导致其它微服务都做调整，在设计之初就要考虑到所有情况，让接口尽量做的更通用，更灵活，从而尽量避免其它模块也做调整。
四、分布式与微服务的区别
从概念理解，分布式服务架构强调的是服务化以及服务的分散化，微服务则更强调服务的专业化和精细分工。
从实践的角度来看，微服务架构通常是分布式服务架构，反之则未必成立。
所以，选择微服务通常意味着需要解决分布式架构的各种难题。
分布式的模块拆分是根据不同业务模块进行拆分并且部署道不同的机器上，各个业务模块之间通过接口进行数据交互。而微服务的拆分则注重功能及耦合度，并且微服务的应用不一定是分散在多个服务器上，他也可以是同一个服务器。
分布式架构：重在资源共享与加快计算机计算速度（分散压力）
微服务架构：重在解耦合，使每个模块都独立（分散能力）
好了，今天的内容到这里就结束了，关注我，我们下期见
- 由于博主才疏学浅，难免会有纰漏，假如你发现了错误或偏见的地方，还望留言给我指出来，我会对其加以修正。
- 如果你觉得文章还不错，你的转发、分享、点赞、留言就是对我最大的鼓励。
- 感谢您的阅读，十分欢迎并感谢您的关注。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
这是一个技术一般，但热衷于分享；经验尚浅，但脸皮够厚；明明年轻有颜值，但非要靠才华吃饭的程序员。
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
