我眼中的ASP.NET Core之微服务 (二)

前言

接上一篇。

上一篇未完待续的原因是当时刚好是6-30号晚上马上12点了还没写完，然后我想赶在7月1号之前发出去，所以当时就发了。然后在发的时候出了一点问题，结果发出去的时候刚好是 7.1号 00:00分，所以就很尴尬~~

这一篇，我们就接着说一说微服务吧。

接上文

第四步，重构。

当你写完代码之后，我认为有一个比较重要的步骤就是对写的代码进行一番重构，重构一般从两方面下手，第一方面是代码的命名以及格式，第二方面是代码的组织结构。

针对于代码命名以及格式的重构其实是有方法和技巧的，比如方法的命名以及方法的拆分等可以从<<重构>>这些书中来获取一些指导意见等，对于代码格式的话基本上现代的IDE都提供了很好的格式化工具，使用便是。

针对于组织结构的重构有时候是需要依赖很多你的经验的，经验丰富的程序员知道如果的去对写过的代码进行抽象，然后利用某种设计模式或者是面向对象的原则来让代码更加的利于维护和扩展，这种技能往往更难掌握，需要你去阅读很多的别人优秀的代码，然后去思考和学习。

OK，以上就是在构建单个微服务程序的个人总结的一些指导原则吧。

部署方式

指导原则可以帮助我们在构建系统的时候使其保持一个良好的结构，但是你还需要从整体上来把控整个微服务的布局。什么意思呢？

我们知道，微服务最良好的部署方式就是使用 Docker 容器进行部署，因为这样便于管理和配置。
在以前的单体结构的项目中也可以使用Docker进行整块的部署，我们可能部署到多个容器中，然后前置一个负载均衡器进行路由的转发，这样也是可以的。

通常情况下，即使我们的程序架构风格不是微服务，那么在组织代码结构时，也会进行模块的划分，比如划分为会员，商品，库存等。下面是一个单体应用整块部署使用Docker的部署图：

但是这种模式其实与容器的初衷是有一点违背的，容器所倡导的是一个容器只做一件事情。整块部署有一个明显的缺点是，如果随着应用程序的扩展那么每次代码的修改都要全部进行重新发布，但是我们经常修改的代码可能就是某一快的功能，而另外一些代码则永远不会动，这样不但发布程序的时候发布包很大，也容易出错，出问题造成的影响也比较广。

比如，在一个电商网站中，有一些模块是经常发生变化的，比如一些促销，产品等页面，这些页面的访问量也很大，而另外一些页面比如用户中心积分查看，历史订单查看这些功能则不会经常变动，并且访问量要小很多。那么如果他们都在一个系统中，势必会引起这些问题：1、性能优化，如果访问量很高的模块出现性能问题，那么你只能针对整个程序进行扩展部署，而不是单个模块。2、测试，由于模块的依赖，那么在修改一块地方的时候，必须重新对整个应用程序进行一次测试，并且重新部署所有这些实例。3、无法进行扩展，你无法简单的进行接口或者服务的扩展，这会使SOA变得很困难。

那么我们就再顺便说一下SOA，我们知道大多数的公司在 .NET FX 时代使用 WCF 技术进行项目的 SOA 化，比如常见简单的会使用 SOAP ,HTTP，MQ等进行通讯，他们也会把系统进行划分（子系统）和分层。听起来可能和微服务有点像，那么他们有什么区别呢？ 想必这是一个很多人讨论过的话题，那么直接说结论吧。 微服务它来自于SOA，但是和SOA不同的是它并没有那么重量级，什么意思呢？比如它没有SOA中的像集群的Broker, 那么大的组织的划分，中央负责人, 还有企业服务总线 (ESB)等。

然后就是我们的主题微服务，微服务架构的定义就是一组小型的服务。每一个服务都位于自己的进程中，并且使用诸如HTTP, WebSockets，或者 AMQP 之类的协议进行通讯。它很小，并且专注于做好一件事，这个很重要，它看起来像OOP中的单一职责原则，如果你2周之内不能完成一个微服务模块，那么可能你对于边界划分出了点问题。

关于微服务的优缺点不做过多的介绍了，有兴趣的同学可以看一下在我博客里面的 Martin Fowler 的 这篇文章。

这篇文章提到了『微服务设计』这本书，如果你想对微服务有更多了解的话可以看一下这本书，建议购买。

微服务中的一些技术挑战

下面需要说的是个人对于在构建微服务的过程中会面临的一些问题，或者说叫做挑战吧。

1、微服务的边界怎么定义。

上一篇文章已经提到过了，在定义微服务边界的过程中，DDD中的指导原则会帮助你大忙。 这可能是你在构建微服务过程中遇到的第一个难题，一个良好的微服务能够对其他微服务尽可能少的依赖，同一个应用程序中你需要用不同的上下文进行解耦，每个上下文有可能是使用不同的程序语言的。这些上下文应该被独立的定义和管理。比如一个User，在 Identity 上下文可能是一个用户，在 CRM 中是一个客户，在订单上下文是一个买家，等等。

2、如何跨微服务进行查询。

因为我们已经微服务化了，所以我们的应用程序数据可能分布在不同的数据库中，那么如何实现从多个为微服务器数据库中查询数据成为一个难题了。

比如，我们前台的数据展示页面需要一个销售统计的报表，其中的数据分别来源于订单，库存和商品。那么我们应该怎么样来处理这种复杂性呢？ 目前流行的解决方案有以下几种：

API网关。 使用API网关来对多个微服务器的数据库进行聚合。 但是在实现这种模式的时候你需要非常的小心，它有可能是你系统中性能的瓶颈，甚至它有可能违背微服务的自治原则。为了尽可能避免这个陷阱，你需要设计多个细粒度的 API 网关，每个网关关注系统一个垂直领域的“切片”区域，或者是一个业务领域。现在大部分的云提供商都提供的有 API 网关相关服务，比如AWS的 Amazon API Gateway，Azure 的 Establish API Gateways 等，借助于这些服务可以方便的对 API 进行管理。

CQRS与读表。 不知道大家有没有听说话物化视图（Materialized View）这个名词。你可以理解为远程视图，使用这种方法，你可以提前准备好一个只读表，其中包括多个微服务的数据，这个只读表的结构和你展示给客户的页面数据是对应的。

那么有同学可能会存在这样一个问题，假如我基于不同的数据库建立一个物化视图，那么在我建立物化视图的过程中，我应该怎么样进行查询，因为对于单个数据库的查询可能仍然是复杂的。确实如此，在以前单个应用程序的时候，我们在呈现个客户端需要的数据的时候，可能会是一个复杂的SQL Join连接查询的结果。那么这里的解决方案就是，我们需要建立一个和我们业务无关的一个单独的数据库，然后这个数据库中会包含一些和界面上需要的数据进行一一对应的一些查询用的表，然后我们应用程序中引入 CRQS 这种模式，将需要的数据写入到这些查询表中。

这不仅解决了跨微服务查询这个难题，并且也提高了性能。但是引入CQRS也就意味着你需要拥抱最终一致性。

数据中心的 “冷数据”。 对于一些不需要做实时数据的复杂查询或者报表，通常是将微服务的“热数据”作为“冷数据”导出到数据中心以供报表。这个数据中心可能是一个基于大数据的系统，比如 Hadoop，AWS的Redshit，Azure的SQL Data warehosue等。

同步的过程你可以使用事件驱动这种通讯技术，或者是一些数据库提供的基础设施中的导入/导出工具等。如果使用事件驱动的话，其过程有点类似上面的CRQS查询过程。

3、如何实现多个微服务的数据一致性。

我们知道在每个微服务都是具有高内聚的特点的，外部想访问微服务的数据只能通过API访问，那么我们在实现一个微服务到另外一个微服务这种业务流程的时候，怎么同时保持多个微服务之间的一致性呢？

我们回到 eShop 这个微软的示例项目上来，来看看怎么处理的。 首先，Catelog 这个微服务是负责维护商品相关的信息，包括库存。 Ordering 这个微服务负责订单的管理，当新创建一个订单的时候，它必须验证这个订单的商品是否具有足够的库存（如果不够可能涉及到缺货登记），所以它就必须要和Catelog微服务打交道。在以前单服务的程序中可以简单的使用ACID事务来进行检查并且直接更新可用库存。但是现在不能这样了，每个微服务都拥有自己的数据库，当前的服务不能直接去操作其他服务的数据库的，这个时候我们为了实现我们需要的功能怎么办呢？我们可以使用异步通讯，比如消息或者事件驱动这种方式，这也是 eShop使用的方式。

这里就涉及到一个理论知识，就是 CAP定理。也就是说你必须要在可用性和ACID强一致性之间做出选择。大多数基于微服务的场景都需要可用性和高可扩展，而不是强一致性。所以为了保证在关键场景下应用程序能够正常响应，我们一般会选择牺牲强一致行从而追求最终一致性。

4、如何跨微服务进行通讯。

微服务之间的通讯，是一个比较大的技术挑战。这个时候你不应该去关注你应该使用什么协议，比如是使用 Http、Rest、AMQP
、消息、或者其他东西。相反，你应该了解每种协议的优缺点，你使用该协议想达到什么样的一个目的，以及这种协议怎么样和你的微服务更好的进行耦合。根据耦合程度，当发生故障的时候，是不是对系统有非常大的影响。

像微服务这种分布式系统中，是由许多的组件在很多的服务器之间共享的。这些组件最终可能会发生故障，当这些组件故障的时候，你需要考虑的是是否会引起更大的故障，所以你需要在设计你的微服务的时候充分考虑到这些通讯过程中常见的风险。

目前一种比较流行的做法是使用基于 HTTP 协议 REST 方式的微服务，这是因为它们很简单。而且基于 HTTP 的这种方式是完全可以接受的，当然这也取决于你当前的使用场景。 假如说你是在客户端或者是API网关中使用 HTTP 进行请求和相应以及进行微服务交互，那么它足够用了。但是，假如你是跨微服务之间进行HTTP的调用长链的话，就像在使用数据库事务那样使用，那么你的应用程序最终会遇到麻烦的问题。

事实上，如果你在内部微服务之间通讯也是通过HTTP的方式，那么我可以理解为你正在使用的是一个单机的应用程序，只是他们是基于进程之间的HTTP，而不是进程内的通讯。

因此，我们在设计微服务的时候，为了其具有更好的弹性，我们应该尽量减少这种跨微服务的通讯。这种情况下，我们可以使基于消息或者事件的异步通讯方式来达到目的。

那么在 .net 中有没有什么现成的解决方案可以用呢？ 答案是肯定的，请向下看。

总结

这一篇主要是对上一篇的一个补充，以及涵盖了微服务的部署方式以及在构建服务器的过程中会遇到的一些技术挑战。

下一节，我们将说一下 基于消息的异步通讯， 我将会给出在 .NET Core 中的具体的解决方案，敬请期待。

本文地址：http://www.cnblogs.com/savorboard/p/aspnetcore-microservice2.html
作者博客：Savorboard
欢迎转载，请在明显位置给出出处及链接