这一章节，我来介绍一下Asp.Net Boilerplate框架在微服务开发中所用到的技术及其大体的组织架构。由于本系列仅讨论ABP框架在微服务架构下的应用方案，不涉及具体的业务逻辑，所以在文中，不讨论服务拆分方案等细节，也未采用中台架构等复杂架构方案，此类方案可依据业务需求进行设计，与Asp.Net Boilerplate框架本身无关。

    虽然Asp.Net Boilerplate和AbpvNext从框架层面有很大区别，会影响到微服务的分层和模块组织方式等细节实现，但是对于微服务的总体架构及技术选型方面差别不大。

    这里，我借用ABPvNext的一张微服务架构示意图：

我们会用到图中提及的一下技术：    

• API网关作为服务调用的总入口，同时负责了负载均衡、身份认证、熔断、限流等功能，Ocelot是基于.NetCore实现的一个主流API网关，对于以.Net技术为主的研发人员来说，更容易使用及修改。

• IdentityServer也是基于.NetCore开发，是ABP官方推荐的身份认证框架。在这里，我们也同样以IdentityServer4作为身份认证中心。

• ELK（Elasticsearch、Logstash、Kibana）是目前最常用的日志服务之一(不仅限于.Net技术栈）,实际使用中，我们通常会有直接写入lasticsearch、使用ELK+Filebeat、ELK+Kafuka等多种方式。
  

• 微服务间通讯方式有同步和异步两种方式，需要依据不同业务场景进行选择。其中同步通讯有多种实现方式，这里我使用了和AbpvNext微服务Demo相同的内外双网关方式，服务间调用通过内网关调用WebAPI接口方式实现。

• AbpvNext提供了跨服务的事件总线机制，但是Asp.Net Boilerplate未对此进行封装和支持，需要我们额外进行开发。

    除此之外，我们还会用到其他一些组成微服务架构必须的技术组件：

• 服务注册和发现采用Consul

• 配置中心采用Apollo
  

• 应用性能监测采用Skywalking

    在此基础上，我们会发现即使我们按照业务聚合拆分了不同的网关，单一网关能够承载的服务数量依旧非常有限。通常我会使用Nginx作为作为上层负载均衡机制，组成网关集群。或依据项目访问量需求，使用云服务提供商提供的SLB组成更加复杂的负载均衡方案。

    最终我们用到的技术模块如下：

    后面几期，我会按照各个模块分别对Asp.Net Boilerplate在微服务架构中的应用细节进行分享，敬请期待……