微服务时代的来临
近两年“微服务架构”被炒的火热，传统软件企业是否能怀抱微服务，从而对软件产品进行一次架构优化升级，似乎一直成为信息系统架构师思考的问题。传统行业对IT效率的变革需求是微服务成长土壤,业务模式创新重塑导致系统更新频繁、应用复杂度急剧升高，传统架构不堪重负。伴随着Spring Cloud开源界各种微服务落地方案的出现和热议，这些企业都积极拥抱了微服务，并在生产环境使用。
现阶段架构总览
着眼“业界”，回头看看目前“作坊”的架构发展到哪个阶段，直接上图：
历史架构.png
目前软件产品系统涵盖多个（20个）模块，或者称为应用，每个应用有独立团队进行开发维护，独立技术线路，且独立部署。有一个基础应用：基础服务SIP，主要负责维护基础数据、认证授权、配置等基础服务，并对各个独立应用提供服务访问，各个业务只负责业务范畴的功能。各个应用之间也存在相互之间的服务依赖和调用，这种调用一般以webservice的形式存在，且服务地址配置往往记录在应用本身。系统外存在移动应用，其部分数据依托于该软件产品，且调用方式为直接发起对目标App的请求。
当前架构问题
通过上一节介绍，轻量级场景下，似乎这种架构方式还能应对，但是笔者只画了3个App，如果补齐20+的应用，那么上图的预览图应该如下：
复杂依赖.png
所以，伴随着系统规模继续扩大，或者需求迭代继续，当前架构似乎的确存在一些问题。
比如：
1、模块之间直接依赖，且服务地址零散配置，形成网状
2、模块服务接口版本任意，版本迭代困难，服务调用方式多样，不便于管理
4、各个App对服务依赖是单线的，服务进行App级别的负载均衡困难
5、移动和第三方应用直接对各个App进行访问，穿透产品边界，且无权限控制
6、配置信息不集中，无有效管理
7、各个App服务状态未知，且容易引起单点
8、服务调用没有可追踪记录，发现问题困难
9、跨服务更新，无事务
10、跨团队接口调用沟通频繁
畅想架构
分析了现阶段架构的痛点，那么借助微服务架构特点，我们可以怎样进行升级或者思考呢，还是直接画图阐述：
架构设想 .png
改造点：
1、单App技术线路统一
2、引入网关层，进行路由和负载均衡
3、引入注册中心，对各个App对内提供的服务进行注册和发现
4、引入配置中心，抽取公共配置，便于统一管理
5、引入基础服务层，支撑多基础服务方集成支持
6、引入日志和监控平台，进行服务调用最终，甚至可以进行容错性熔断
7、高并发下，可以进一步采用7层或者4层LB，对网关进行负载均衡
8、个别应用间可引入分布式事务，进行数据一致性保障
9、App应用可独立部署，便于Paas平台运行
畅想架构难点
这种改造的优点，显然对各个应用进行了更好的治理，但是同时也带来了很多难点：
1、"应用外服务设施"变多，对软件产品整体部署和运维带来困难
2、需要更多基础技术架构团队的技术支撑
3、基础服务层，需多种平台的实现（Supos\BAP）
4、团队技术能力提升
网友评论