微服务简介讲解学习

2，微服务由来
微服务最早由MARTIN FOWLER与JAMES LEWIS于2014年共同提出，微服务架构风格是一种 使用一套小服务来开发单个应用的方式途径，每个服务运行在自己的进程中，并使用轻量 级机制通信，通常是HTTP API，这些服务基于业务能力构建，并能够通过自动化部署机制 来独立部署，这些服务使用不同的编程语言实现，以及不同数据存储技术，并保持最低限 度的集中式管理。
3，为什么需要微服务？
在传统的IT行业软件大多都是各种独立系统的堆砌，这些系统的问题总结来说就是扩展性 差，可靠性不高，维护成本高。到后面引入了SOA服务化，但是，由于 SOA 早期均使用了 总线模式，这种总线模式是与某种技术栈强绑定的，比如：J2EE。这导致很多企业的遗留 系统很难对接，切换时间太长，成本太高，新系统稳定性的收敛也需要一些时间。最终 SOA 看起来很美，但却成为了企业级奢侈品，中小公司都望而生畏。
3.1 早期的单体架构带来的问题
单体架构在规模比较小的情况下工作情况良好，但是随着系统规模的扩大，它暴露出来的问题 也越来越多，主要有以下几点： 1. 复杂性逐渐变高 • 比如有的项目有几十万行代码，各个模块之间区别比较模糊，逻辑比较混乱，代码越多复
杂性越高，越难解决遇到的问题。 2. 技术债务逐渐上升 • 公司的人员流动是再正常不过的事情，有的员工在离职之前，疏于代码质量的自我管束，
3. 单体架构所有的模块开发所使用的技术一样，微服务每个模块都可以使用不同的开发 技术，开发模式更灵活。
3.3 微服务与SOA区别
微服务，从本质意义上看，还是 SOA 架构。但内涵有所不同，微服务并不绑定某种特殊的 技术，在一个微服务的系统中，可以有 JAVA 编写的服务，也可以有 PYTHON编写的服务， 他们是靠RESTFUL架构风格统一成一个系统的。所以微服务本身与具体技术实现无关，扩 展性强。
导致留下来很多坑，由于单体项目代码量庞大的惊人，留下的坑很难被发觉，这就给新来 的员工带来很大的烦恼，人员流动越大所留下的坑越多，也就是所谓的技术债务越来越多。
3. 部署速度逐渐变慢
• 这个就很好理解了，单体架构模块非常多，代码量非常庞大，导致部署项目所花费的 时间越来越多，曾经有的项目启动就要一二十分钟，这是多么恐怖的事情啊，启动几 次项目一天的时间就过去了，留给开发者开发的时间就非常少了。
4. 阻碍技术创新
• 比如以前的某个项目使用STRUTS2写的，由于各个模块之间有着千丝万缕的联系，代码 量大，逻辑不够清楚，如果现在想用SPRING MVC来重构这个项目将是非常困难的，付 出的成本将非常大，所以更多的时候公司不得不硬着头皮继续使用老的STRUTS架构， 这就阻碍了技术的创新。
5. 无法按需伸缩
1. 单体架构所有的模块全都耦合在一块，代码量大，维护困难，微服务每个模块就相当 于一个单独的项目，代码量明显减少，遇到问题也相对来说比较好解决。
2. 单体架构所有的模块都共用一个数据库，存储方式比较单一，微服务每个模块都可以 使用不同的存储方式（比如有的用REDIS，有的用MYSQL等），数据库也是单个模块对 应自己的数据库。
4. 微服务本质
1. 微服务，关键其实不仅仅是微服务本身，而是系统要提供一套基础的架构，这种架构 使得微服务可以独立的部署、运行、升级，不仅如此，这个系统架构还让微服务与微 服务之间在结构上“松耦合”，而在功能上则表现为一个统一的整体。这种所谓的 “统一的整体”表现出来的是统一风格的界面，统一的权限管理，统一的安全策略， 统一的上线过程，统一的日志和审计方法，统一的调度方式，统一的访问入口等等。
能不能做成微服务，取决于四个要素：
• 小：微服务体积小，2 PIZZA 团队。 • 独：能够独立的部署和运行。 • 轻：使用轻量级的通信机制和架构。 • 松：为服务之间是松耦合的。
6. 微服务折分与设计
1. 从单体式结构转向微服务架构中会持续碰到服务边界划分的问题：比如，我们有USER 服务来提供用户的基础信息，那么用户的头像和图片等是应该单独划分为一个新的 SERVICE更好还是应该合并到UΒιβλιοθήκη BaiduER服务里呢？如果服务的粒度划分的过粗，那就回到 了单体式的老路；如果过细，那服务间调用的开销就变得不可忽视了，管理难度也会 指数级增加。目前为止还没有一个可以称之为服务边界划分的标准，只能根据不同的 业务系统加以调节
5. 什么样的项目适合微服务
微服务可以按照业务功能本身的独立性来划分，如果系统提供的业务是非常底层的，如： 操作系统内核、存储系统、网络系统、数据库系统等等，这类系统都偏底层，功能和功能 之间有着紧密的配合关系，如果强制拆分为较小的服务单元，会让集成工作量急剧上升， 并且这种人为的切割无法带来业务上的真正的隔离，所以无法做到独立部署和运行，也就 不适合做成微服务了。
2. 微服务的目的是有效的拆分应用，实现敏捷开发和部署 。
3. 微服务提倡的理念团队间应该是 INTER-OPERATE, NOT INTEGRATE 。INTER-OPERATE是定 义好系统的边界和接口，在一个团队内全栈，让团队自治，原因就是因为如果团队按 照这样的方式组建，将沟通的成本维持在系统内部，每个子系统就会更加内聚，彼此 的依赖耦合能变弱，跨系统的沟通成本也就能降低
微服务
"让我们的系统尽可能快地响应变化" - REBECCA PARSON --------实现自我包含，单一业务功能的自治服务。
3/4/2019
1，什么是微服务
微 狭义来讲就是体积小，著名的"2 PIZZA 团队"很好的诠释了这一解释（2 PIZZA 团队最早 是亚马逊 CEO BEZOS提出来的，意思是说单个服务的设计，所有参与人从设计、开发、测 试、运维所有人加起来 只需要2个披萨就够了 ）。 而所谓服务，一定要区别于系统，服 务一个或者一组相对较小且独立的功能单元，是用户可以感知最小功能集。
• 比如说电影模块是CPU密集型的模块，而订单模块是IO密集型的模块，假如我们要提升 订单模块的性能，比如加大内存、增加硬盘，但是由于所有的模块都在一个架构下， 因此我们在扩展订单模块的性能时不得不考虑其它模块的因素，因为我们不能因为扩 展某个模块的性能而损害其它模块的性能，从而无法按需进行伸缩。
3.2 微服务与单体架构区别