如何在微服务时代更好的让系统的架构看起来自然和顺畅一点呢？结合这段时间的学习和思考，总结如下的一种架构模式：
通常情况下，服务能够提供数据，那是因为有信息的输入到系统中，排除外部系统同步过来的情况下，正常情况下，数据的收集一般是通过页面，由用户进行录入的，所以，正常的情况下，都需要提供一个web-ui给到用户进行操作，即UI-VIEW应用，这里的UI-VIEW是指前后端分类的架构。
用户输入的信息，进行后台保存时，一种方式是直接调用API-GW进行保存操作。按照这样的模式，服务层的应用，需要支持全部的外围系统的所有诉求及个性化差异。相像一下，把参数验证，权限验证，业务逻辑处理，数据导入，数据导出做在一个服务接口中实现，同时还应当来着不同的外围系统的个性化需求。这是一种什么样的体验。所以，都应该在业务服务之前，设计一层很薄的应用或者分层，用来将一些简单逻辑，比如参数验证，权限控制，个性化参数封装的逻辑进行包装。
基于上述的一些考虑，所以才有上面的架构图。
按照上述的架构图，将每个小模块主要处理的功能进行定义如下：
UI-VIEW：主要作用是提供用户可视化的操作界面，信息输入，修改，删除，查询等功能，处理一下简单的数据转换等等。
WEB-MGR：接收可视化界面操作的数据，并进行用户的权限验证，参数验证，数据的转换，接口服务编排等等功能。
Service：将业务拆分成细粒度，比较独立的服务操作，比如新增数据服务，删除数据服务，数据分页查询服务等等。
想起来一个最近开发的一个需求，按照需求对应到上面的架构图中，看看是否合理。
需求：用户最近对公司提供的云产品服务进行梳理，原来的产品主要是根据云的容量进行区分，比如CPU，内存，宽带，存储空间等进行划分，初，中，高级产品服务。现在需要加入承若的服务时效进行进一步区分，分为初-8，初-16，初-24等等。
一种实现方式是将最开始的主产品进行新增服务时效字段然后进行区分，但是这样的改动会影响到历史数据及历史的账单。
所以，我们采用的方案是，单点设计主产品对应的承若服务时效的价格方案。比如初-8的价格是之前产品价格的30%。
回到系统架构上来看，我们需要做的事情包括：
1、新增维护界面，维护主产品对应的承若服务时效的价格方案。
2、提供服务接口查询主产品对应的承若服务时效的价格方案。
3、修改原来对外的主产品选择页面及报价显示。
对于1和2点，没有啥太多的讨论点，下面主要针对3的进行描述一下：
对于3的新的产品和架构，我只需要在web-mgr应用中，查询完主产品信息和价格之后，在调用一次已经配置的服务时效承若，然后按照服务时效承若配置，计算出最新的产品信息及价格，返回给到页面中。
伪代码：
List<> productList = call productMaster();
List<> limitationList = call productlimitation()；
List<> resultList = new
limitationList.foreach(
tempObj.setlimitation(tempObj.getlimitation)
tempObj.setproduct(product.getproduct(tempObj.getproduct)
tempObj.setprice(product.getPrice()*tempObj.getRateprice())
resultList .add(tempObj);
);
总结：基础服务没有改变，我只是通过修改了web-mgr应用，就实现了整个需要，对任何外围系统没有影响。减少了影响的范围。
核心的思路就是，服务本身尽量少变，通过引入服务编排的方式进行形成新的服务。
写在最后：
软件体系中，没有完全的对或者错，应该或者不应该，仅仅是个人偏好导致每个人对相同问题解决方案的不一致。
欢迎大家留意讨论，共同进步。
网友评论