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