微服务下的视角

拆分微服务的目的，目前的企业服务架构下，除了应对量大而设计的分层过滤，还有就是中台建设。从阿里巴巴中台战略中了解到，早起的淘宝系统，是“烟囱型”架构，从业务侧垂直往下构建服务，而同属阿里集团的其他服务是不存在互通的。我们可以想象，用户体系、订单体系、优惠券等几十个公用服务每个业务都有一套，还不互通，这样造成的问题是：一、同一集团产品账号体系不互通，会员体系相互割据；二、同一个用户的数据需要到两个不同系统进行查询；三、功能浪费。
还有一个重要的原因，是中台建设之后，前台业务是十分灵活的，便于短期产生产品进行市场试错，如果是属于每套系统都是独立的，那么每次有新产品或者内部创业的时候，就要从轮子开始造起，不仅引起工程人员加班几点，还会使得错过市场最佳时机；商场如战场，一分一秒的领先都将带来巨大的利润。

一般性企业级服务使用的组件

Java以非常齐全的生态圈制霸服务端开发领域，无论是阿里开源的dubbo还是spring cloud，其配套的组件亦是开源的，使得企业在构建微服务架构的时候多了很多便利。所以，时下的互联网企业大多关注业务本身，如何更好地进行业务扩展，适应新的市场需求是企业的核心诉求。
中台建设，可以使得企业将关注点彻底关注在业务扩展上，不仅使得技术人员脱离一些重复编码的劳动，还可以制造更多产值。

企业级协作模型

企业协作.png

在中小型企业的实践中，微服务必须的jar包存在自建的私库中，需要使用别的业务团队的产品，则只需要导入对方的dependency就好了；而业务团队的迭代、业务文档、以及服务器运维系统，为团队效率做了支撑。

企业级微服务结构

微服务.png

在使用spring cloud进行微服务实践的时候，我们总结出了一套类似这样的架构。在我们业务域中的抽象模型如图所示。
我们对服务进行垂直切分，根据业务特性划分为若干个核心服务，而核心服务只提供能力，在能力的组合上我们产生了规则引擎。规则引擎的主要工作是组合若干个业务并封装成一个特定的流程，并管理流程的进度、校验、完成等工作。在规则引擎之上，我们称之为产品层，属于我们业务域在公司层面的可用产品，比如对外售卖的接口、售卖的整个服务、以及业务上下游的交互。
在这套体系结构中，合法性、权限校验的工作交给了网关层，网关的请求必须通过鉴权，才能进入我们的业务产品。而由于产品形态的原因，若是API的产品，则直接携带鉴权信息请求网关即可；若是我们的整套解决方案的售卖（包含页面）的时候，鉴权我们采用了webserver作为鉴权参数转发的中继。
在这套服务架构下的优势，就是规则引擎与核心服务的改变是非常少的，而业务是千变万化的，因此对于场景化、定制化的需求我们只需要在webapplication中完成就好了。规则引擎因什么而改变？比如我需要新增规则，提供新的能力的时候我们可以在规则引擎中进行配置。规则引擎的设计应该是可以通过配置化实现新增规则的功能，但很可惜我们实践的规则引擎是静态规则引擎，需要进行硬编码提供接口的方式来新增流程。核心能力何时改变？在我们的一个核心服务中，它的功能是对接三方进行数据验证，当我们需要对接新的三方供应商的时候，这样就需要去改变它了。我提到的改变，大多数都是横向扩展、增量改变。
这套结构的好出就是，我们建立了一个中台的模型，上层的业务改变，内核只做配置或者少量的新增。

企业级实践的关注

无论是传统IT还是互联网企业，在提供服务的时候最核心的考虑点，就是服务的可用性。在我们的实践中，总工的要求是99.95%，大概一年的业务中断实践仅4个小时。因此，我们需要了解高可用的技术方案与思路。
（1）基于负载均衡的高可用方案
实践中我们使用的eureka作为注册中心，而每一个服务都是集群配置。通常的LB的算法配置，是加权轮询，并且注册中心有定时探活的机制，如果某台服务器挂了，那么这个ip列表将会从eureka中移除，使得其他服务的rpc调用不会走到这个有问题的服务器上。
我们知道eureka是AP系统，所以不是立马就能同步所有的节点，在rpc发起的时候，依然可能走到这台挂的服务上造成故障。因此我们配套了服务告警系统，可以使得owner第一时间知道问题并着手处理。
（2）rpc调用超时设置
中台服务间的交互，使用的是rpc的方式，如果一个服务响应时间过长，再量增长的场景下，有可能使得web服务的线程耗尽，造成业务等待或者中断的情况。所以我们设置了rpc超时时间，但这仅仅解决了服务向下游服务产生调用防御自身的效果，有时候下游服务处理完成发现超时了，就会导致一些数据不一致问题，因此还需要配套一些补偿或者分布式事务的机制。
（3）基于QPS的拒绝方案
阿里提供的中间件，Sentinel使用滑动窗口的机制对每秒的qps进行统计，如果达到阈值就进行限流拒绝的策略。如果业务不发起，则就不会有数据不一致的问题，所以我们应用在了网关上。
（4）流量削峰
假如数据库的写入量限制是2000，而写入忽然大到10000，那怎么办。这种写入或者说业务峰值，不是常有的，所以我们使用消息队列进行削峰。在业务执行的时候，我们将写入请求存入消息队列，使用适合数量的消费者，去进行库的写入，这样就像是生产者再怎么大量生产，写入速度依然是恒定的，这个方案对消息队列的可用性要求很高。
（5）数据灾备
业务数据需要进行分时、分日或者一个周期进行冗余备份，加入发生了意外可以采用备份恢复。