微服务架构介绍

微服务架构介绍

微服务体现在一个"微"字

技术架构演变

单体应用

Model1模式：jsp+Java
Model2模式(MVC模式)：Model View Controller （web service dao）

垂直应用

就是把单体应用拆分为模块。

RPC分布式应用

每一个模块都是一个项目 ，每个项目之间来回的调用

SOA流动计算架构

在RPC的技术只上，引入dubbo做一些资源调度、负载均衡、动态服务创建...服务治理

微服务

把SOA在拆分成小的项目.微服务体现微字，单一职责。可以看做是SOA的一种补充

什么是微服务

把一个单体架构的应用划分为一个个的独立运行的程序即服务.他们之间通过HTTP协议进行通信(也可以采用消息队列来通信，如：MQ,kafaka等)，可以采用不同的编程语言，使用不同的存储技术，自动化部署(如kafaka)减少认为控制，降低出错概率，服务数量越多，管理起来越复杂，因此采用集中化管理。例如Eureka、Zookeeper等都是比较常见的服务集中化管理框架。
微服务是一种架构风格，一个大型的复杂软件应用，由一个或多个微服务组成。系统中的各个微服务肯呢过被独立部署，每个微服务之间是松耦合的，每个微服务仅关注于完成一件任务并很好的完成该任务。

优点

简单、灵活、独立部署，专注、专业、高效、可靠、小团队，松耦合、高内聚、易扩展，与语言、工具无关，测试容易，课伸缩性强，可靠性强，跨语言，协同开发，方便系统化迭代。

缺点

1.依赖服务接口变更：服务接口如何管理、接口变更跟踪难、依赖服务测试麻烦
2.部分模块重复构建：安全认证、配置日志
3.分布式带来的问题：分布式事务问题、依赖服务不稳定，需要引入异步模式
4.运维复杂度徒增：部署物数量倍增、监控进程倍增、故障定位难、问题追朔难
5.运维承办高，部署项目多，接口版本兼容问题，分布式系统的复杂性，分布式事务

SOA vs MicroServices

面向服务架构(SOA)是一种用于设计软件的伟大原则。在SOA中，所有组件都是独立自主的，并能为其他组件提供服务。大体上，SOA与微服务架构是非常相像的。那么它们之间的区别到底是什么呢？微服务是细粒度的SOA组件。换句话说，某单个SOA组件可以拆分成多个微服务，而这些微服务通过分工协作，可以提供与原SOA组件相同级别的功能。
微服务是细粒度的SOA组件，它们是关注更窄的轻量级服务。微服务推崇执行的标砖(例如HTTP)是人们广泛了解并共同使用的。我们可以通过选择合适的语言或工具来构建某个组件(微服务)，除了技术栈与微服务规模之外，在SOA与微服务之间还有一个更大的区别：领域模型。在一个基于微服务的软件中，每个微服务应该在本地存储自身管理的数据，并将领域模型分别隔离到单个服务中。而在面向SOA的软件中，数据往往存储在单个大型的数据库中，服务之间会共享领域模型。

SOA与微服务架构对比

SOA	微服务架构
应用程序服务的课重用性的最大化	专注于解耦
系统性的改变需要修改整体	系统性的改变是创建一个新的服务
DevOps和持续交付正在变得流行，但还不是主流	强烈关注DecOps和持续交付
专注于业务功能重用	更重视"上下文边界"的概念
通信使用企业服务总栈ESB（Enterprise Service Bus）	对于通信而言，使用较少精细和简单的消息系统
支持多种消息协议	使用轻量级协议，列如HTTP、REST或Thrift APA
对于部署到它的所有服务使用通用平台	应用程序服务器不是真的被使用，通常使用云平台
容器(如Docker)的使用不太受欢迎	容器在微服务方面效果更好
SOA服务共享数据存储	每个微服务可以有一个独立的数据存储
共同的治理和标准	轻松的治理，更加关注团队协作和选择自由

总结：微服务是SOA发展出来的产物，它是一种比较现代化的细粒度的SOA实现方式。

Dubbo vs SpringCloud

1.Spring全家桶 ：用起来很舒服，只有你想不到，没有它做不到
2.Dubbo:很多国内的企业还在用，可以支持RESTful风格的API,调用远程API像调用本地API一样，同时其基于接口的方式增加了微服务的耦合

SOA	微服务架构	Dubbo
服务注册中心	Eureak	Zookeeper,Nacos
服务调用方式	REST API	RPC
服务网关	Zuul	Dubbo Proxy
断路由	HyStrix	Sentinel
分布式配置	Config	Nacos
服务跟踪	Sleuth	无
消息总线	Bus	无
数据流	Stream	无
批量任务	Task	无

总结:
1.Dubbo由于是二进制的传输，占用宽带更少
2.SpringCloud是http协议传输，宽带会比较多，同时使用http协议一般会使用JSON报文，消耗会更大
3.Dubbo的开发难度较大，原因是Dubbo的jar包依赖问题很多大型工程无法解决
4.SpringCloud的接口协议约定比较自由且松散，需要有强大的行政措施来限制接口无序升级
5.Dubbo的注册中心可以选择ZooKeeper Redis等多种，SpirngCloud的注册中心只能使用eureka或者自研
6.从系统结构简易程序：SpringCloud的系统结构更简单、“注册+MVC=Cloud”，而Dubbo各种复杂的url,protocol，register,invocation,dubbofilter,dubboSPI,dubbo序列haul…炫技的成分更多一些
7.从性能：Dubbo的网络消耗小于Cloud,但是在国内95%的公司，网络消耗不是什么太大问题，如果成了问题，可以通过压缩、二进制、高速缓存、分段降级等方法，很容易解决。

微服务设计原则

AKF拆分原则

业界对于可扩展的系统架构有朴素的理念，就是：一台机器不行那就两台。
AKF公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，课将一个单体系统。进行无限扩展。
AKF拆分为XYZ轴模式然后按照不同的服务功能进行拆分
拆分要点：低耦合、高内聚，即一个服务完成一个独立的功能；按团队结构，小规模团队维护，快速迭代
X轴：指的事水平复制。就是将单体系统多运行几个实例，成为集群加负载均衡的模式
Y轴：就是我们所说的微服务的拆分模式，就是基于不同的业务拆分
Z轴：是基于类似的数据分区。比如北京、河北、河南、浙江等多建立几个数据区域

前后端分离原则

前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前段的用户体验优化效果更好
前后端分离模式下，前后端交互更清晰，就剩下了接口模型，后端的接口简单明了，更容易维护。
前后端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支持多个前端：列如：微信H5前端、PC前端、安卓前端、IOS前端。

无状态服务

状态分为无状态和有状态：一个请求没有上下文关系,
比如：一个按键没有对应工具操作改变了自身数据，但工具数据未改变。
运行无状态服务之后在按一次按键，会将按键对应的数据为条件对工具进行更改；
而有状态服务则之后更改一次工具的数据
而微服务需要将服务状态设置未无状态服务。这样可以将按钮数据和工具数据进行同步

Restful通信风格

其实就是一种约束一种规范。比如：get获取资源，post添加资源，put更新资源 ，delete删除资源

设计原则总结

推荐优选Restful风格，因为好处多
无状态协议HTTP，具备先天优势，扩展能力很强。例如需要安全加密时，有现成的成熟方案HTTPS可用。
JSON报文序列化，轻量简单，人与机器均可读，学习成本低，搜索引擎友好。
语言无关，各大热门语言都提供成熟的RestfulAPI框架，想对其他的一个RPC框架生态更完善