微服务架构 如何影响传统的软件架构设计
ThoughtWorks首席咨询师王磊通过一个互联网门户案例为大家解释了微服务架构的概念，以及它如何影响传统的软件架构设计。
一年前，该门户每签一个10万的合同所耗费的成本是3.5天。他们当时的CRM结构是典型的三层架构，整个应用程序由一个40万行的代码库组成，后端有一个主动的数据库。虽然使用三层架构的成本比较小，但随着代码和功能的增加，代码库不断膨胀，修改代码存在的风险很大，整个维护成本也变得越来越高。
每当开发人员提交代码后，所需的数据集成和构建需要50分钟，意味着每天8小时工作时间最多能有9次代码提交。但为了系统的稳定性，持续集成过程中要尽量避免提交代码，因此，整个团队的交付能力受到了限制。此外，从准备部署包到上线需要3天，3天后才能让用户真正用到部署包，才能实现价值。而如果增加新人，要开发新的环境，包括测试和产品环境，培养周期会很长。针对以上难题，ThoughtWorks制定了如何在团队中对系统进行改造从而满足业务需求的策略。
将现有的系统保护起来，把所有开发新功能的优先级都降下来，只需对系统做最紧急的修改，其他和部门进行协商，让团队保持新的精力和时间在重要的业务上。
功能剥离。通过定义新服务，在前端用一些代码的机制让用户逐渐访问新服务，可以达到从原有系统抽出小功能，让客户访问小功能。
数据解耦。对于庞大的系统，因为无法很快将所有系统换掉，所以为了保证系统仍然可用，要启用数据同步机制，让服务里的数据同步到原有数据库。
渐进替换。通过不断地运行以上策略，将原有系统的复杂功能抽离出来用新的方式来做。
目前，每签一个10万的合同所耗费的成本由3.5天变为1天，持续集成构建从50钟降低到18分钟，团队成员从10人降到7人，部署周期由3天降到2小时。
对于每个应用程序，可能有一组小的服务组成，每个服务运行在自己的进程中，服务与服务之间通过轻量级的机制进行交互。那么，如何使用微服务做系统改造呢?
为每个服务建立独立的环境，包括基础设施、持续集成环境、运维、监控、日志聚合、报警。
不断演进的微服务开发模板，发现问题及时修改，让模板更高效。
轻量级的通信协议。
消费者的契约测试，解决随着服务增多带来集成测试效率低的问题。
基础设施自管理，帮助管理自己需要的资源。
微服务框架 spring cloud 和 dubbo 有什么区别
dubbo由于是二进制的传输，占用带宽会少，springCloud是http协议传输，带宽会比较多，同时使用http协议一般会使用JSON报文，消耗会更大
dubbo的开发难度较大，原因是dubbo的jar包依赖问题很多大型工程无法解决
springcloud的接口协议约定比较自由且松散，需要有强有力的行政措施来限制接口无序升级
dubbo的注册中心可以选择zk,redis等多种，springcloud的注册中心只能用eureka或者自研
微服务的优点
微服务是指提供单个业务功能的服务，从技术角度看就是一种小而独立的处理过程，类似流程概念，能够自行单独启动或销毁，拥有自己独立的数据库。
一个复杂软件架构是由很多这样小而独立运行（有自己的端口）微服务组成，这些独立处理组件之间通讯是通过与语言无关的API进行，简单协议有同步性质的RMI/RPC和 RESTful Web Services，异步的消息推送和Reactive方式。
这些模块化的方式能够使得公司将项目分解分散到多个开发团队，跨不同业务部门，提供非常充分的灵活性，帮助提高项目的生命周期，加快项目开发完成效率。
每个微服务组件都有自己分配的存储 内存和CPU资源，这就使得硬件利用更加易于优化和跟踪，特别是在基于云的Pass环境，开发团队可以使用他们喜欢的技术，任何语言都可以，只要确保微服务之间是可交互的，能够最终组合起最后的应用。
当管理复杂性会因为采取微服务架构而降低，通常更新其中一个微服务组件不会引起连锁反应，因为微服务之间是松耦合的。
目前使用微服务的企业有：Netflix Twitter Amazon Web Services (AWS), Google, eBay等。
因为有很多应用和服务部署在基于云主机的环境中，微服务架构将会严重依赖容器技术，容器隔离了微服务处理过程，将一个应用切分为一个个小的实例，这些容器中的小实例有自己的端口和虚拟化环境。
广泛使用的容器技术是Docker, 一种基于Linux的开源实现，由很多软件公司支持如 Canonical, Red Hat,和Parallels. PaaS服务支持包括Google App Engine, Red Hat Open Shift,和VMware的 Cloud Foundry,。
-微服务系统架构图
