标签：自动 挑战 通讯 耦合度 技术 发展 传统 修改 消息中间件
一、微服务架构的定义
1、定义
微服务是架构设计上的一种风格，他的主旨是通过将一个原本独立的系统拆分成多个小型服务。这些小型服务彼此进程独立，彼此之间通过基于http的restful服务通讯写作。
被拆分的每个小型服务围绕着系统中某一项或一些耦合度较高的业务功能进行构建，并且每个服务维护者自己的数据存储、业务开发、自动化测试用例以及独立的部署机制。
由于有了轻量级的通信写作基础，这些微服务可以使用不同的语言和架构来编写。
2、特性
五毒特性，分别演进
3、微服务架构 vs 传统架构模式
传统服务架构-单体应用模式
在业务发展初期，业务逻辑在一个应用中，开发测试方便。随着企业发展，需求不断增多，系统功能模块不断增加。
特别是随着移动端设备的发展，前端展现已经不止局限于web方式。
单体应用弊端：
- 部署在一个进程中，每个功能的修改部署可能会影响其他功能
- 各个功能使用场景、并发量、消耗的资源各不相同，资源利用相互影响，很难准确评估
随着系统的发展，单体应用维护成本越来越大，且难以控制。
微服务架构优势：
- 开发维护容易，不影响其他功能运行
- 独立部署，性能容量评估容易，容易发现系统瓶颈
4、挑战
- 运维的新挑战：自动化运维，编排运维过程
- 接口的一致性：接口和版本管理
- 分布式的复杂性：网络延迟、分布式事务、异步消息等
二、微服务架构的九大特性
1、服务组件化：独立演进而不影响其他单元
2、按业务组织团队：一体化团队，降低内耗，边界清晰
3、做产品的态度：对产品生命周期负责
4、智能端点和哑管道：rest服务和消息中间件实现消息易读和可视化
5、去中心化治理：不同的业务场景可以选择不同的技术平台
6、去中心化管理数据：无事务和最终一致性
7、基础设施自动化：自动化测试和自动化部署
8、容错设计：快速发现故障和快速自动回复
9、演进式设计：初期单体&玻璃经常变动和有一定时间效应的内容鹅绒给技术
三、微服务架构的选择：Spring Cloud
1、当前的解决方案
- 服务治理：DubboX，Dubbo、Nexflix的Eureka、Apache的Consul
- 分布式配置管理：百度的Disconf、Netflix的archaius、360的QConf、SpringCloud的Config、淘宝的Diamond
- 批量任务：当当网的Elastic-job、LinkedIn的Azkaban、SpringCloud的Task等
- 服务跟踪：京东的Hydra、SpringCloud的Sleuth、Twitter的Zipkin等
- 。。。
2、综合解决方案：Spring Cloud
兼容机与品牌机的故事
兼容机：自己选择合适的组件，整合框架，技能要求高，兼容性需要验证
品牌机：不重复造轮子，集成特性完备
SpringCloud：借助社区的力量，聚焦业务开发
微服务：什么是微服务架构？
标签：自动 挑战 通讯 耦合度 技术 发展 传统 修改 消息中间件
原文地址：http://www.cnblogs.com/lexiaofei/p/7647683.html
