Java生鲜电商平台-微服务架构概述

Java生鲜电商平台-微服务架构概述

 

单体架构存在的问题

在传统的软件技术架构系统中，基本上将业务功能集中在单一应用内，或者是单一进程中。尽管现代化的软件架构理论以及设计原则已推广多年，但实际技术衍化的速度迟缓而且变革动力不足。 其中的缘由存在着复杂性以及多样性，我想主要的缘由是没有一套总体的解决方案可以让工程师在面临稳定性风险下，毅然决然地实施系统重构。当系统应用规模随着业务的迅速发展时，系统的重要性愈发突出，开发人员将对系统的改造尤其敏感，从以前的徘徊犹豫，随之变得更加保守，只能延续过去的技术方案，将功能不断地累积在原有的系统架构上。这样的系统比如是豆腐叠罗汉，叠得越高越危险。所以，当面临巨大的服务压力时，系统不得不经过扩容的方式，来支撑应对。俗话说，“船小好调头”，“头病医头，脚病医脚”。臃肿的系统使得扩容变得毫无针对性，牵一发而动全身。因为服务运行状况存在差别性，具体哪一个功能存在性能瓶颈，又因服务并不是孤立而存在，使得评估结果存在着主观臆断性和不肯定性，这种相互影响和做用下，使得扩容变得异常的困难，扩容没法量化，最终致使“水桶效应”。

当应用场景规模增大时，为了提升了开发以及执行的效率，而且使得更优雅或者合适的解决问题成为可能，开发人员将会评估和选择更先进的技术，推进演进。因为系统应用过度地集中了全部功能，其功能所需依赖服务以及执行库文件也随之变得庞大，当须要适配新的技术时，不只依赖冲突难存在不肯定性而且难以应付，进而使代码重构变得异常困难，增长了适配新技术的难度。

正由于功能集中于一身，让应用资源占用率变得愈来愈大，使得持续集成、回归测试、以及分发部署变得愈发困难。好比，应用部署包磁盘占变多，让编译、打包、分发以及启动时间变长，不肯定性因素变得更大。当应用发布上线后，存在功能性缺陷，须要回滚时，这样的试错和时间成本变得更加昂贵。

越是功能集中式的系统架构，在开发工程中，越依赖于与执行环境。这种执行环境承载着数据、服务以及配置，如若其中那个环节出现问题，开发进程不得不被迫中断，而不断地诊断问题和调试环境，使得快速开发变得要不可及，更不要说在本地开发。因为对环境的过度依赖，使得系统的稳定性变得更不肯定性。其一，因为服务相互依赖，而服务又依赖环境，开发人员对单元测试职业习惯以及依赖程度下降，使得测试环节减小，或者说更依赖于集成测试。其二，当测试人员在部署测试环境执行集成测试时，不但部署成功率不断地下降，并且执行过程时间不断地增长，压缩了开发时间，也可能致使项目滞后。不只提升了系统风险，而且增长了心理负担。这么说来，不管是快速开发和测试都变得更加艰难。

以上分析还只是停留在那些熟悉业务和技术的成员，当业务快速发展时，其发展速度与开发效率比不断扩大，招募和发展新人是必不可少的手段。当面对如此巨大和复杂的系统应用时，业务和技术所需的知识变得特别杂糅，让新人有一种“独上高楼望，尽天涯路”之感，学习曲线陡峭。在实际的实施过程当中，文档完整性以及指导的系统性皆存在不足。

如何解决单体架构存在的问题

单体应用给咱们带来的现实问题：

• 扩容困难（Problems in scalability ）
• 部署困难（Problems in deployment）
• 发布回滚困难（Problems in release rollback）
• 适配新技术困难（ Problems in adopting new technologies ）
• 快速开发困难（Problems in RAD）
• 测试困难（Problems in testing）
• 学习困难（Problems in learning）

实际上，在解决单体应用的问题上，数年前，就出现了相应的解决方法，好比SOA的技术路线。

SOA解决一个现实的问题，那就是服务与服务之间解耦，将古老的进程内服务调用，经过网络协议转化成服务之间的调用。从早期发明了CORBA、RMI、COM+、XML-PPC等技术，不过问题也随之出现，因为这些技术绑定在某种技术或者平台，好比RMI属于Java 平台技术，COM+属于微软技术体系，XML=PRC没有统一的协议标准，所以对平台无关性的通信须要的协议呼声强烈，这时一些典型的技术陆续出现，如WebServices以及MessageQueue。以及它们的集大成技术ESB。

其中的表明技术有：WSDL（Web Service Definition Language）、SOAP（Simple Object Access Prototol）等技术。因为这些通信协议标准相对笨重，虽然目前仍在被普遍的使用，但逐步被淘汰是大势所趋。

为何不选SOA而选微服务

面向服务架构（SOA） VS 微服务

类同

• 面向服务（ Service-Oriented ）
• 松耦合（Loose-Coupling）
• 自包含（Self-Contained）
• 平台无关性（Independent Platform）

差别

• 原子性（Atomic）
• 自治性（Autonomous）
• 开发运维体系（DevOps）
• 轻量级（Lightweight）
• 通信协议（Communication Protocol）

微服务是粒度小的SOA，正因为SOA体系庞大，不可能实现更好的原子性，而且它采用了统一统治的方式，例如ESB那样的大型解决方案。这样技术选型，针对单一的服务没法实现自行管理，无形之中增长了团队运维成本。开发人员不能很好的实施DevOps技术手段。同时，SOA采用了WSDL、SOAP等重量级的通信协议，增长了开发成本以及性能损耗。在微服务中，大多数服务API经过REST的方式暴露，这样大大地下降了适配的成本。

微服务是趋势

让咱们看看google和百度统计的结果吧

 

图片.png

图（1）Google中spring boot的搜索热度

spring boot和spring cloud是作微服务的最佳搭档。从图（1）上，咱们可以看到spring boot 2013年在全球开始流行，一直到2017年2月到了100的热度。

 

图片.png

图（2）google中spring cloud的搜索热度

从图（2）上，咱们能够看到spring cloud从2012年开始热度都是比较平和，在2015年6月以后，也就是微服务开始兴起的时候，spring cloud开始迅速增加，在2017年2月达到了100的搜索热度。（地图上没有中国，估计是由于中国被墙掉了的缘由）

 

 

图（3）百度搜索中spring boot的搜索热度

图（3）是百度地图统计的结果，咱们能够看到spring boot在国内是2015年6月开始流行的，2017年增加尤其突出。

 

 

图（4）百度搜索中spring cloud的搜索热度

图（4）咱们能够看到，spring cloud是从2016年6月开始在中国流行，每每新技术要在中国流行，都会落后硅谷一年，看看一年前的硅谷，就是如今的中国，因此你们也就可以判断到了spring cloud在中国的发展曲线了，也就是2018年2月spring cloud在中国的热度将达到顶峰。

虽然流行并不表明你须要。可是，既然流行就有他流行的缘由，就有他优势。后面咱们将回来认识下微服务。

什么是微服务

微服务是用一组小服务的方式来构建一个应用，服务独立运行在不一样的进程中，服务之间经过轻量的通信机制（如RESTful接口）来交互，而且服务能够经过自动化部署方式独立部署。正由于微服务架构中，服务之间是相互独立的，因此不一样的服务可使用不一样的语言来开发，或者根据业务的需求使用不一样类型的数据库。

微服务架构的优势与挑战

优点

• 服务简单，只关注一个业务功能
  传统的总体风格的架构在构建部署和扩展伸缩方面有很大的局限性，其服务端应用就像是一块铁板，笨重且不可拆分，系统中任何程序的改变都须要整个应用从新构建和部署新版本。在进行水平扩展时也只能整个系统扩展，而不能针对某一个功能模块进行扩展。 而微服务架构将系统以组件化的方式分解为多个服务，服务之间相对独立且松耦合，单一功能的改变只须要从新构建部署相应的服务便可。

• 每一个微服务可由不一样团队开发
  传统的开发模式在分工时每每以技术为单位，好比UI团队、服务端团队和数据库团队，这样的分工可能会致使任何功能上的改变都须要跨团队沟通和协调。而微服务则倡导围绕服务来分工，不一样的服务能够采用不一样的技术来实现，一个团队中应该包含开发所需的全部技能，好比用户体验、数据库、项目管理。

• 微服务是松散耦合的
  微服务架构抛弃了ESB复杂的业务规则编排、消息路由等功能，微服务架构中服务是高内聚的，每一个服务都会处理相应的业务，全部的业务逻辑应该尽可能在服务内部处理，且服务间的通讯尽量的轻量化，好比使用Restful的方式。

• 可用不一样的编程语言与工具开发
  传统的软件开发中常常会使用同一个技术平台来解决全部的问题，而经验代表使用合适的工具作合适的事情会让开发变得事半功倍。微服务架构天生就具备这样的特性，咱们可使用Node.js来开发一个简单的报表页面，使用C++来编写一个实时聊天组件。

挑战

• 运维开销
  更多的服务也就意味着更多的运维，产品团队须要保证全部的相关服务都有完善的监控等基础设施，传统的架构开发者只须要保证一个应用正常运行，而如今却须要保证几十甚至上百道工序高效运转，这是一个艰巨的任务。

• DevOps要求
  使用微服务架构后，开发团队须要保证一个Tomcat集群可用，保证一个数据库可用，这就意味着团队须要高品质的DevOps和自动化技术。而如今，这样的全栈式人才不多。

• 隐式接口
  服务和服务之间经过接口来“联系”，当某一个服务更改接口格式时，可能涉及到此接口的全部服务都须要作调整。

• 重复劳动
  在不少服务中可能都会使用到同一个功能，而这一功能点没有足够大到提供一个服务的程度，这个时候可能不一样的服务团队都会单独开发这一功能，重复的业务逻辑，这违背了良好的软件工程中的不少原则。

• 分布式系统的复杂性
  微服务经过REST API或消息来将不一样的服务联系起来，这在以前可能只是一个简单的远程过程调用。分布式系统也就意味着开发者须要考虑网络延迟、容错、消息序列化、不可靠的网络、异步、版本控制、负载等，而面对如此多的微服务都须要分布式时，整个产品须要有一整套完整的机制来保证各个服务能够正常运转。

• 事务、异步、测试面临挑战
  跨进程之间的事务、大量的异步处理、多个微服务之间的总体测试都须要有一整套的解决方案，而如今看起来，这些技术并无成熟。

微服务设计原则

• 隔离
  服务必须设计为单独相互隔离工做。当你将一个总体单片系统分解成一组服务时，这些服务必须彼此解耦，这样才能更加连贯和自给自足。每一个服务应该可以处理其本身的故障，而不会影响或破坏整个应用程序或系统。隔离和解耦特性使服务可以很是快速地从故障状态中恢复。服务的隔离特性具备如下优势：容易采用连续交付，更好的扩展，有效的监控和可测试性。

• 自治性
  隔离为自治性铺平了道路。 服务必须设计为自主自治的。它必须具备凝聚力，可以独立地实现其职能。每一个服务可使用良好定义的API（URI）独立调用。API以某种方式标识服务功能。自主服务还必须处理本身的数据。更流行的术语是多语言持久性，其中每一个服务都有本身的持久存储。 自主还确保弹性。自主服务具备如下优势：有效的服务编排和协调，更好的扩展，经过良好定义的API进行通讯，更快速和可控的部署。

• 单一责任
  服务必须设计为高度凝聚。单一的职责（责任）原则是服务只执行一个重要的功能。 单一责任与“微观”一词很好地结合。‘微’意味着小，细粒度，只与其责任范围内相关。单一责任功能具备如下优势：服务组合无缝，更好的扩展，可重用性，可扩展性和可维护性。

• 有界上下文
  您的服务应该有多大或小？ 答案就在于所谓有界上下文设计原则。这是一个关键模式，同时是领域驱动设计（DDD）建模方法。有界的上下文是关于微服务将提供其服务功能的上下文。它根据有关领域模型和识别离散边界，并相应地设计您的微服务，使其更具凝聚力和自主性。这也意味着跨边界的通讯变得更有效率，在一个有界上下文中的服务不须要依赖于另一个有限上下文中的太多的事情了。

• 异步通讯
  在设计离散边界和使用其本身的有界上下文设计服务时，跨边界的服务通讯必须是异步的。异步通讯模式天然致使服务之间的松耦合，并容许更好的缩放。使用同步通讯，会阻止调用并等待响应。 处于阻塞状态的服务不能执行另外一个任务，直到接收到响应并释放底层线程为止。它致使网络拥塞，并影响延迟和吞吐量。异步通讯还能够带来实现良好定义的集成或通讯模式的概念，以实现涉及不一样服务的逻辑工做流。

• 位置独立 根据设计，微服务是在虚拟化环境或docker容器中部署。随着云计算的出现，咱们能够拥有大量能够利用动态缩放环境的服务实例。服务能够在跨小型或大型集群的多个节点上运行。服务自己能够根据底层计算资源的可用性或效率来从新定位。必须可以以位置独立的方式来寻址或定位服务。一般，可使用不一样的查找发现模式来消费使用您的服务。服务的客户端或消费者没必要烦恼部署或配置特定服务的位置。它只是使用某种逻辑或虚拟地址来定位服务。