如今框架两字已经烂大街了，xx公司架构设计随处可见，不过大多看个热闹，这些框架如何来的，细节又是如何思考的，相互之间的隔离依据又是什么...相信很多朋友应该依然存在自己的疑惑，特别是越来越火热的微服务以及衍生的微服务网关产品，正好最近打算写一个小开源框架oss.core，过程中有一点思考，通过这篇文章记录一下，也希望能尽量帮助大家去理解一下，大概围绕以下几个问题：
1. 微服务产生的由来2. 微服务的设计思路3. OSS.Core框架的设计和实现
在展开讲述之前，我希望大家首先要明白传统架构和微服务架构之间不是相互独立/对立关系，微服务是在传统框架下为了应对并发维护等问题衍生出的逻辑概念，更多的是在项目不同阶段的思考和解决问题方式的转变。其次，把逻辑架构和物理架构(文件) 区分开来，多数时候逻辑架构和物理架构对应的，不过有时一个物理架构中是可以包含多个逻辑架构的。
一. 微服务产生的由来
微服务主要是将一些大型的，复杂的应用拆解为多个服务组合，每个服务自治，以达到更加灵活，维护方便的效果。
为了更好的理解，我们先来看下常见三种解决并发的方式：
1. 添加数据库主从分离，甚至多主写入或者分区等机制，在应用程序中对应修改连接串或添加访问中间件，来提高数据库的处理能力。
2. 由于数据库资源相对紧张并且比较耗时，为了提高访问速度，这个时候一般也会通过分布式缓存等来减少对底层的访问。
3. 负载均衡分流处理，在大量请求抵达应用程序之前，将其分散到不同的机器上，来解决单机带宽和性能瓶颈问题。
当然解决并发还有很多其他的方式，如前端静态文件压缩，CDN加速，IP速率控制等，这里先略过。
以上这三种方法很多朋友应该都见过，之所以这里列一下，再结合这张图可以更加容易的对比出传统整个服务到微服务之间的变化：
在传统的整体服务框架中，模块之间存在着很大的耦合，项目内部存在互相调用，以及各种复杂聚合操作，所以在多数情况下只能整体部署，在左侧图中我们可以看到负载均衡时我们需要整体部署在多台机器上，相对数据库也是如此，而一个项目中每个模块的需求是不一样的。
例如：产品和下单模块的访问频率和流程的复杂度上有着很大的不同，下单频率相对较小，复杂度高，我们更希望运行在预算能力高的相对少机器上，也方便更快的排查问题和维护。右图中可以看到把服务细化之后，我们可以用更小的部署单元来根据情况进行组合。
同时，在互联网产品快速迭代的今天，一个产品需要具有快速为不同终端上线不同应用功能的能力，同时业务的调整能够快速的上线，传统的整体服务模式已经力不从心。微服务因为已经化整为零，反而因为各模块的独立能很快相互组合，并且每个模块可以根据不同的需求点采用不同特性的编程语言。
二. 微服务的设计思路
因为每个产品都有自己的标准和重点，所以设计服务单元时也各有不同，但是有最基本一点： 服务自治
当你设计一个微服务模块时，需要保证当前服务的独立，特别是数据模块的独立，其他服务无权直接操作当前服务下的数据库模块，对外交互只能通过服务接口来完成。因为模块的独立，所以你可以选择适合的编程语言，以及对应的部署规模。达到局部的灵活优化。微服务相互独立带来以上便利的同时，它也带来了一些我们需要面对的问题：
首先：如何如何界定当前服务的边界，如何确定当前服务治理范围。
既然是要最小化服务单元，那就要确定服务的职责边界问题，这个问题建议结合：服务生命周期流程，领域，以及预估规模 这几点综合考虑，例如用户服务，在访问量小人员少时可以把用户基础信息，余额账户放在一个服务模块下，以减少工作量减少精力分散。规模大时再分基础服务和资产服务。
其次：跨服务数据查询问题
例如在客户端中搜索商品，还可以搜索用户或者统计数据查询等如何处理。对于这种我给两个处理方式：
1. API Gateway
这种情况适合在服务单元过多，客户端需要查询使用不同的服务单元中的数据，这个时候我们可以针对性的搭建一个API服务网关（请注意和APP Gateway区分开），通过这个网关聚合多个服务，客户端只需要和当前网关交互，网关聚合转发给不同的微服务。如下图：
2. 数据冗余或者后台数据同步
比如在订单信息中我需要用户的名称等少量用户字段，这个时候完全可以把这几个字段冗余到订单微服务数据模块下。又比如在统计模块下，其数据制造者和查询者完全属于不同的对象，无很高实时性，那我建议创建一个统计服务以及对应的统计数据库，其他服务通过事件消息交互，更新对应的统计数据，查询时通过统计服务自己的数据即可完成。
再次：如何解决服务间的通信问题
因为我们已经将服务之间相互独立，断绝直接操作不同服务数据库的可能。那么数据的一致性如何处理，在传统的服务模型中因为都糅合在一块，我们可以通过事务或者存储过程来保证数据的一致性。常见的有以下两个方式：
1. 异步事件消息驱动
这类解决方案适合对数据实时性要求相对不高的场景，比如上边的统计服务更新，在下单等服务的事件触发后给消息队列推送响应的消息通知，订阅此队列的服务接收更新数据。如图：
2. 直接接口请求（HTTP,RPC）
一般情况下不建议，以防止产生级联依赖。这类主要针对数据实时性要求较高的请求，比如在秒杀下单过程中需要立即知道库存服务扣除是否成功等。（注：.net 下对task的支持已经特别好了，http请求建议使用异步，同时前端返回TaskActionResult>,减少因IO操作造成的工作线程消耗）
最后：客户端如何访问
当我们封装完服务之后，这个服务如何和最后的客户端如何访问，这个需要根据实际的安全规则和要求各自决定了，一般情况下，如果服务相对较少，功能不算复杂的情况下可以直接暴露服务接口给客户端进行访问，如图：
或者通过上边说的 API Gateway 的形式提供给客户端，当然也有很多已经成熟的微服务网关比如Azure云上的Service Fabric或者API Management，都是可以的。
三. OSS.Core框架的思路和实现
OSS.Core这个项目是我最近在写的一个小开源产品，了解的朋友应该知道我在前面写了一些组件像: OSS.Social，OSS.PayCenter，OSS.Common，OSS.Http 这个项目希望能把这几个组件给串联起来，上边已经介绍了微服务的大概思考方式，我将会在这个产品的逻辑架构中尽可能的体现这一点，先把项目的物理架构图展示一下：
这个项目中AdminSite，WebSite 放置在FrontEnds文件夹下，两个问站点分别是用户前端，和后台管理前端
WebApi，Service，DomainMos（图中的Models和Interface）类库在 Layers 文件夹下，构成API基础
Infrastructure（业务相关通用实体枚举辅助类） 和 Common（业务无关相关实体辅助类） 作为基础设施类库，可以在各级类库中调用
Repositories（暂时是项目中的OSS.Core.RepDapper的Mysql实现，以后可能增加其他数据库支持），主要是Rep.. Interface的具体实现。
Plugs是实现了Common插件下的日志，缓存，和配置接口具体实现，可以通过Common在各级直接调用。
回到微服务的话题上，在这个产品中我不会为每个服务创建一套Layers下的类库实现，我将在这个项目通过文件夹隔离的形式来分开各个服务，你可以把WebApi当做一个API Gateway，内部的调用顺序我希望是这样的：
现在代码结构图：
