surging微服务框架剥析-微服务入门篇

suring是基于.netcore的高性能的分布式微服务框架surgingisbasedon.netcorelanguagehigh-performancedistributedmicroservicesframework框架剥析微服务入门篇讲解网站架构的演变过程、微服务如何设计？遵循什么设计原则Surging基础入门详细介绍Surging,与其它微服务有何区别。Surging入门浅析讲解Surging如何搭建微服务、基于配置文件和代码如何配置、如何拆分微服务Surging网关浅析讲解网关服务管理、数据安全、数据监控、流量控制、身份认证、分流控制和网关统一的入口访问深入剥析Surging剥析框架，深入理解Surging,理解微服务的设计思路0102030405课程提纲应用架构演化过程单体应用架构垂直应用架构微服务应用架构微服务入门篇讲解网站架构的演变过程、微服务如何设计？遵循什么设计原则入门篇单体应用简介一、什么是单体应用一般通过引用将所有功能在同一程序实现中的应用，我们通常称之为单体应用。二、单体应用简介在面临各种业务需求时，通常会把功能堆积到同一个单体应用中去。比如：常见的ERP、CRM等系统都以单体应用进行架构，单体应用业务流程往往在同一个进程内部完成处理，不需要进行分布式协作。单体应用架构一、单体应用的架构：在单体应用架构中，经常提及和使用经典的3层模型，即表示层、业务逻辑层和数据访问层。表现层：用于直接和用户交互，也称为交互层，通常是网页、UI等。业务逻辑层：即业务逻辑处理层，例如用户输入的信息要经过业务逻辑层的处理后，才能展现给用户。数据访问层：用于操作数据库，用户在表示层会产生大量的数据，通过数据访问层对数据库进行读写操作。应用程序DALUIBLL单体架构优点与缺点一、单体架构优点易于开发：IDE针对于单体应用的开发、部署、调试而设计的，所以利用IDE就能短时间开发出单体应用。易于测试：单体应用不需要依赖其它接口运行，安装部署完成后就可以开始测试，简化了测试的过程，节约测试的时间易于部署：只需把文件复制或者安装到指定文件下，就已经部署成功一、单体应用缺点1.逻辑复杂、模块耦合、代码臃肿，修改难度大，版本迭代效率低下2.系统启动慢，一个进程包含了所有的业务逻辑，涉及到的启动模块过多，导致系统的启动、重启时间周期过长3.系统错误隔离性差、可用性差，任何一个模块的错误均可能造成整个系统的宕机4.可伸缩性差；系统的扩容只能只对这个应用进行扩容，不能做到对某个功能点进行扩容5.线上问题修复周期长；任何一个线上问题修复需要对整个应用系统进行全面升级什么是垂直应用一、什么是垂直应用前端界面和业务逻辑分层拆分成独立部署的应用就叫做垂直应用WEBAPIMVC垂直应用简介一、垂直应用简介当访问量逐渐增大，单体应用已经不能满足需求，然后将应用分层拆分独立部署，以提升效率。比如常见的eshop、app应用等系统都以垂直应用进行架构。前端和后端业务分层拆分在不同的进程服务器中。垂直应用前端架构在垂直应用前端架构中，会使用MVC去架构，MVC全名是ModelViewController，是模型(model)－视图(view)－控制器(controller)的缩写，一种软件设计典范，用一种业务逻辑、数据、界面显示分离的方法组织代码，将业务逻辑聚集到一个部件里面，在改进和个性化定制界面及用户交互的同时，不需要重新编写业务逻辑。MVC被独特的发展起来用于映射传统的输入、处理和输出功能在一个逻辑的图形化用户界面的结构中。视图:用户与之交互的界面模型:就是业务流程/状态的处理以及业务规则的制定控制器：用户接收请求,将模型与视图匹配在一起，共同完成用户的请求。一、垂直应用前端架构ControllerViewModel垂直应用后台架构在垂直应用后台架构中，通常会使用SOA架构，SOA是一种粗粒度、松耦合服务架构，服务之间通过简单、精确定义接口进行通讯，不涉及底层编程接口和通讯模型,它可以更加从容地应对复杂企业系统集成和需求的快速变化,并且按照相关的标准或协议，进行分层开发。通过这种分层设计或架构体系可以使软件产品变得更加弹性和灵活，且尽可能的与第三方软件产品互补兼容，以达到快速扩展，满足或响应市场或客户需求的多样化、多变性。一、垂直应用后台架构DDD领域驱动设计SOA服务架构MVC前端架构垂直应用优点与缺点一、垂直应用优点一、垂直应用缺点2.团队协作效率差，功能重复开发。1.复杂应用开发的维护成本很高，部署效率低。3.可靠性差，容易引起雪崩效应4.维护困难，随着功能越来越多，无法针对功能进行服务拆分，修改会造成其它功能性的错误1.更高的可用性:该特点是在于后端服务提供者和前端调用者的松散耦合关系上得以发挥与体现。前端无须了解提供者的具休实现细节。2.更好的伸缩性:依靠业务服务设计、开发和部署等所采用的架构模型实现伸缩性。使得服务提供者可以互相彼此独立地进行调整，以满足新的服务需求。3.更易维护:当需求发生变化的时候，不需要修改提供业务服务的接口，只需要调整业务实现即可，整个应用系统也更容易被维护微服务介绍一、什么是微服务(Microservices)二、微服务特点2.服务进程隔离：服务独立开发、编译、部署、测试、发布，有独立工程、独立版本、接口契约化1.服务组件化：应用拆分服务运行在不同进程中，每个服务有明确的边界3.去中心化：针对业务选择不同的编程语言，针对性的解决问题4.智能终端：业务逻辑在服务内部处理，服务之间通信使用轻量高性能通信机制微服务架构是一种粒度更细小服务来开发单个应用，每个服务运行在自己的进程中，并使用TCP或HTTP进行通信，这些服务使用不同的编程语言实现，采用网关集中式管理和外网访问。5.更高容错能力：内部有一套完整的容错机制来进行熔断，以防止雪崩效应6.统一管理：通过网关统一访问，可以针对服务进行管理、数据监控、身份认证、流量控制、分流控制。微服务通信机制一、通信机制•通知（也就是常说的单向请求）：客户端请求发送到服务端，服务端不返回请求响应。•请求/响应：客户端向服务器端发起请求，同步等待响应，等待过程可能造成线程阻塞。•请求/异步响应：客户端发送请求到服务端，服务端异步响应请求。客户端不会阻塞，而且被设计成默认响应不会立刻到达。•发布/订阅模式：客户端发布通知消息，被零个或者多个订阅者服务消费。•发布/异步响应模式：客户端发布请求消息，然后异步或者回调服务发回响应。微服务异步通信一、基于消息的异步通信消息由头部（元数据）和消息体构成，生产者发送消息到channel,消费者则通过channel接受数据，channel则分为点对点和发布订阅，点对点Channel会把消息准确发送到消费者，之间采用的是一对一的交互模式。而发布/订阅则把消息PUB到所有从channel订阅消息的消费者中，之间采用的一对多的交互模式二、基于请求/异步响应通信模式请求/异步响应的IPC机制是客户端向服务端发送请求，服务端处理请求，异步响应，客户端不会因为等待服务返回而阻塞其它请求。PublisherEventBuspublishSubscriberSubscriberTopicpublishBroadcast/SubscribeBroadcast/SubscribeEventBusBroadcast/publish微服务异步通信2三、基于消息的异步通信消息由头部（元数据）和消息体构成，生产者发送消息到channel,消费者则通过channel接收数据，channel则分为点对点和发布订阅，点对点Channel会把消息准确发送到消费者，之间采用的是一对一的交互模式。而发布/订阅则把消息Publish到所有从channel订阅消息的消费者中，之间采用的一对多的交互模式微服务的设计原则一、AKF拆分原则AKF扩展立方体，是一个叫AKF的公司的技术专家抽象总结的应用扩展的三个维度。理论上按照这三个扩展模式，可以将一个单体系统，进行无限扩展。X轴：指的是水平复制，很好理解，就是讲单体系统多运行几个实例，做个集群加负载均衡的模式。Z轴：是基于类似的数据分区，比如一个互联网打车应用突然或了，用户量激增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。微服务的设计原则一、AKF拆分原则Z轴：是基于类似的数据分区，比如一个互联网打车应用突然用户量激增，集群模式撑不住了，那就按照用户请求的地区进行数据分区，北京、上海、四川等多建几个集群。Y轴：就是我们所说的微服务的拆分模式，就是基于不同的业务拆分。场景说明：比如12306，一个集群撑不住时，分了多个集群，后来用户激增还是不够用，经过分析发现是用户访问量很大，就将12306拆成了六个独立的部署的服务，分别是用户服务、订单服务、余票查询服务、票价计算服务、实名制确认服务、支付服务。六个服务的业务特点各不相同，独立维护，各自都可以再次按需扩展。微服务的设计原则二、前后端分离前后端分离原则，简单来讲就是前端和后端的代码分离也就是技术上做分离，我们推荐的模式是最好直接采用物理分离的方式部署，进一步促使进行更彻底的分离。不要继续以前的服务端模板技术，比如JSP，把JavaJSHTMLCSS都堆到一个页面里，稍复杂的页面就无法维护。这种分离模式的方式有几个好处：前后端技术分离，可以由各自的专家来对各自的领域进行优化，这样前端的用户体验优化效果会更好。分离模式下，前后端交互界面更加清晰，就剩下了接口和模型，后端的接口简洁明了，更容易维护。前端多渠道集成场景更容易实现，后端服务无需变更，采用统一的数据和模型，可以支撑前端的webUI\移动App等访问。微服务的设计原则三、无状态服务对于无状态服务，首先说一下什么是状态：如果一个数据需要被多个服务共享，才能完成一笔交易，那么这个数据被称为状态。进而依赖这个“状态”数据的服务被称为有状态服务，反之称为无状态服务。那么这个无状态服务原则并不是说在微服务架构里就不允许存在状态，表达的真实意思是要把有状态的业务服务改变为无状态的计算类服务，那么状态数据也就相应的迁移到对应的“有状态数据服务”中。微服务分布式缓存分布式数据库分布式存储场景说明：例如我们以前在本地内存中建立的数据缓存、Session缓存，到现在的微服务架构中就应该把这些数据迁移到分布式缓存中存储，让业务服务变成一个无状态的计算节点。迁移后，就可以做到按需动态伸缩，微服务应用在运行时动态增删节点，就不再需要考虑缓存数据如何同步的问题。微服务的设计原则四、内网RPC通信，外网网关通信针对于内网通信，一般采用RPC通信，能够降低性能的损耗，而不同语言，不同的语言环境，不同的网络环境一般我们采用网关进行通信微服务遵守的规则一、微服务遵守的规则2.服务治理根据制定的规则进行配置3.网关根据设计的规则进行调用4.缓存根据规则进行配置和调用1.各个服务需要遵守的通用规则谢谢！suring是基于.netcore的高性能的分布式微服务框架surgingisbasedon.netcorelanguagehigh-performancedistributedmicroservicesframework