Asp.Net Boilerplate微服务实战（二）架构解析
这一章节，我来介绍一下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在微服务架构中的应用细节进行分享，敬请期待……