微服务介绍及Asp.net Core实战项目系列之微服务介绍

0、目录

---

 总体架构目录：ASP.NET Core分布式项目实战-目录

 

1、微服务选型

---

在作微服务架构的技术选型的时候，咱们以“无侵入”和“社区活跃”为主要的考量点，未来升级为原子服务架构、量子服务架构的时候、甚至恢复成单体架构的时候，代价最小。所以软件开发只须要组装，再也不须要从头开发。

选型也能够参考一下张队长的文章：微软MVP张善友告诉你，微服务选型要注意这些地方

2、微服务架构是什么？

---

 按照个人理解介绍一下微服务架构是什么吧。

每个微服务都是一个零件，并使用这些零件组装出不一样的形状。微服务架构就是把一个大系统按业务功能分解成多个职责单一的小系统，并利用简单的方法使多个小系统相互协做，组合成一个大系统。
服务之间互相协调、互相配合，为用户提供最终价值，每一个服务运行在其独立的进程中，服务于服务间采用轻量级的通讯机制互相协做，一般是基于HTTP协议的RESTful API或者RPC。
说白了其核心思想：把大系统拆分为小系统。

3、微服务组件

---

服务注册：服务提供方将本身调用地址注册到服务注册中心，让服务调用方可以方便地找到本身。

服务发现：服务调用方从服务注册中心找到本身须要调用的服务的地址。
负载均衡:
服务网关：服务网关是服务调用的惟一入口。
配置中心:
API管理：
集成框架：微服务组件都以职责单一的程序包对外提供服务，集成框架以配置的形式将全部微服务组件（特别是管理端组件）集成到统一的界面框架下，让用户可以在统一的界面中使用系统。
分布式事务：保证数据的一致性
调用链 ：记录完成一个业务逻辑时调用到的微服务，并将这种串 行或并行的调用关系展现出来。在系统出错时，能够方便地找到 出错点。 （监控）
支撑平台：因为微服务化后，系统变得更加碎片化，系统的部署、运维、监控等都比单体架构更加复杂，就须要用到自动化.

4、微服务架构优点？为何要采用微服务架构？

---

 

微服务与单体的比较，可看下图：

看到上面是否是以为咱们能够用微服务啦，可是要用微服务须要知足必定的条件，以下：（只有复杂、大项目采用）

何时选用微服务呢？

从我的来看，有三种场景能够考虑使用微服务
一、规模大 ，团队超过10人
二、业务复杂度高，系统超过5个子模块
三、须要长期演进，项目开发和维护周期超过半年

 

5、快速体验微服务架构

---

 要想体验微服务，只要轻轻松松四个步骤，以下：

使用微服务简单模式进行开发的四个步骤：
一、沿用组织中现有的技术体系开发单一职责的微服务
二、服务提供方将地址信息注册到注册中心，调用方将服务地址从注册中心拉下来。
三、经过门户后端（服务网关）将服务API暴露给门户和移动APP。
四、将管理端模块集成到统一的操做界面上。

 

是否是get到技能啦！！！

6、运维

---

 这一步是项目的最终实现，固然这里也须要不少技术的配合，想了解devops的请持续关注个人博客吧。

基础设施：自动构建、自动部署、日志中心、健康 检查、性能监控等功能
gitlab-CI/CD、Jenkins+gitlab-CI/CD：自动化部署
K8s&Docker+Jenkins&Pipeline+Gitlab--CI/CD：自动化部署
ELK:日志
zipkin/skywalking：微服务监控

7、总结

---

 

咱们只须要在开发 层面理解了注册中心、服务发现、负载均衡、服务网关和管理端集成框架， 在运维层面准备好持续集成工具、配置中心和监控告警工具，就能够很容 易地落地微服务架构，享受微服务架构带来的精彩。祝你们玩得愉快。

  

8、微服务架构API的开发与治理

---

 

一、开放给互联网用户调用的API须要在API网关上加上受权、鉴权、限流、限并发、统计、计费等功能

二、内网环境：提供给内网里的其余微服务调用的API。

一、内网环境API开发

---

 

一、须要先考虑是用HTTP API仍是RPC？

HTTP API：
指的是简单的基于HTTP协议的API，具体的例子就是MVC的Controller,
http://127.0.0.1/helloworld

RPC:
远程过程调用(大多数指Socker通讯方法的远程调用)，也可使用HTTP协议来实现RPC调用，例如gRPC.

HTTP 简单、RPC基于Socket的RPC性能更好。但我最后仍是选择了HTTP API来使用。

二、HTTP API 的性能足以支撑多数项目

RPC的协议吞吐量是HTTP性能的几倍，如 protobuf、Thrift、Kyro、Dubbo
等，在考虑自身技术栈、成本、稳定性、易用性、可维护性、业务场景等因素考虑，HTT和RPC的性能差异并非主要问题。

 

 

9、如何保障微服务架构下的数据一致性（粗略的介绍）

---

 

 

以电商平台为例，当用户下单并支付后，系统须要修改订单的状态并
且增长用户积分。因为系统采用的是微服务架构，分离出了支付服务、订 单服务和积分服务，每一个服务都有独立数据库作数据存储。当用户支付成 功后，不管是修改订单状态失败仍是增长积分失败，都会 形成数据的不 一致。

 

然而微服务架构下，每一个微服务都有本身的数据库，致使微服务架构 的系统不能简单地知足 ACID，咱们就须要寻找微服务架构下的数据一致性解决方案：

CAP是指在一个分布式系统下，包含三个要素：：Consistency（一致性）、 Availability（可用性）、Partition tolerance（分区容错性），而且 三者不 可得兼。
C:全部数据变更都是同步的
A：即在能够接受的时间范围内正确的相应用户请求
P：分区容错性，即某节点或网络分区故障时，系统仍能提供知足一致性和可用性的服务。
在分布式系统下，为了保证模块的分区容错性，只能在数据强一致性和可用性之间作平衡。具体表现为在必定时间内，可能模块之间数据是不一致的，可是经过自动或者手动补偿后可以达到最终的一致。

分享咱们是如何保证微服务架构的数据一致性的：

一、可靠消息最终一致性（适用于跨平台技术栈不统一的场景）

利用MQ组件实现的二阶段提交，涉及三个模块：
A、上游应用，执行业务并发送MQ消息
B、可靠消息服务和MQ消息组件，协调上下游消息的传递，并确保上下游数据的一致性。
C、下游应用，监听MQ的消息并执行自身业务。

二、TCC方案

涉及三个模块：主业务、从业务、活动管理器
一、主业务服务分别调用全部从业务服务的try操做，并在活动管理器中记录全部从业务服务。当全部从业服务try成功或者某个从业服务try失败时，进入第二阶段。
二、活动管理器根据第一阶段从业服务的try结果来执行confirm或cancel操做。若是第一阶段全部从业务服务都try成功，则协做者调用全部从业服务的confirm操做，不然，调用全部从业务服务的cancel操做。
Confirm 失败：则回滚全部 confirm 操做并执行 cancel 操做。
Cancel 失败：从业务服务须要提供自动 cancel 机制，以保证 cancel 成功。

 写到这里，我已经词穷了，由于针对数据一致性问题，要考虑的很是多。上面的写的不够完善

等有机会，我会专门开设关于微服务架构结合DDD实现数据强一致性和最终一致性的问题探讨。

楼主努力学习中。

 

 

参考地址：

张队长文章：微软MVP张善友告诉你，微服务选型要注意这些地方

 

asp.net Core 交流群：787464275 欢迎加群交流
若是您认为这篇文章还不错或者有所收获，您能够点击右下角的【推荐】按钮精神支持，由于这种支持是我继续写做，分享的最大动力！

做者：LouieGuo

声明：原创博客请在转载时保留原文连接或者在文章开头加上本人博客地址，如发现错误，欢迎批评指正。凡是转载于本人的文章，不能设置打赏功能，若有特殊需求请与本人联系！

微信公众号：欢迎关注                                                 QQ技术交流群： 欢迎加群