微服务简介

解析微服务架构系列文章将分几篇描述微服务的定义、特点、应用场景、企业集成架构的演进以及微服务转型思路和技术决策考虑等内容，并以IBM技术为例介绍如何实现微服务架构转型。为什么需要微服务架构“微服务”架构是近期软件应用领域非常热门的概念。让我们先来看看传统IT架构面临的一些问题： 使用传统的整体式架构(Monolithic Architecture)应用开发系统，如CRM、ERP等大型应用，随着新需求的不断增加，企业更新和修复大型整体式应用变得越来越困难；随着移动互联网的发展，企业被迫将其应用迁移至现代化UI界面架构以便能兼容移动设备，这要求企业能实现应用功能的快速上线；许多企业在SOA投资中得到的回报有限，SOA可以通过标准化服务接口实现能力的重用，但对于快速变化的需求，受到整体式应用的限制，有时候显得力不从心；随着应用云化的日益普及，生于云端的应用具有与传统IT不同的技术基因和开发运维模式。此外，从技术方面看，云计算及互联网公司大量开源轻量级技术不停涌现并日渐成熟：互联网/内联网/网络更加成熟；轻量级运行时技术的出现(node.js, WAS Liberty等)；新的方法与工具(Agile, DevOps, TDD, CI, XP, Puppet, Chef…)；新的轻量级协议(RESTful API接口, 轻量级消息机制)；简化的基础设施：操作系统虚拟化(hypervisors), 容器化(e.g. Docker), 基础设施即服务 (IaaS), 工作负载虚拟化(Kubernetes,Spark…)等；服务平台化(PaaS)： 云服务平台上具有自动缩放、工作负载管理、SLA 管理、消息机制、缓存、构建管理等各种按需使用的服务；新的可替代数据持久化模型：如NoSQL, MapReduce, BASE, CQRS等；标准化代码管理：如Github等。 这一切都催生了新的架构设计风格 – 微服务架构的出现。 什么是微服务微服务是一种架构风格，一个大型复杂软件应用由一个或多个微服务组成。系统中的各个微服务可被独立部署，各个微服务之间是松耦合的。每个微服务仅关注于完成一件任务并很好地完成该任务。在所有情况下，每个任务代表着一个小的业务能力。 微服务的概念源于2014年3月Martin Fowler所写的一篇文章“Microservices”(http://martinfowler.com/articles/microservices.html)。 尽管“微服务”这种架构风格没有精确的定义，但其具有一些共同的特性，如围绕业务能力组织服务、自动化部署、智能端点、对语言及数据的“去集中化”控制等等。 微服务架构的思考是从与整体应用对比而产生的。 其中，对应用组件封装的方式是整体架构与微服务架构的主要差异，微服务架构将相关联的业务逻辑及数据放在一起形成独立的边界，其目的是能在不影响其他应用组件(微服务)的情况下更快地交付并推出市场。 微服务架构的一些通用特性根据MartinFowler的分析，微服务架构有以下的一些通用特性，但并非所有微服务架构应用都必须具备所有这些特性：通过服务实现应用的组件化(Componentizationvia Services)：微服务架构中将组件定义为可被独立替换和升级的软件单元，在应用架构设计中通过将整体应用切分成可独立部署及升级的微服务方式进行组件化设计。围绕业务能力组织服务(Organizedaround Business Capabilities)：微服务架构采取以业务能力为出发点组织服务的策略，因此微服务团队的组织结构必须是跨功能的（如：既管应用，也管数据库）、强搭配的DevOps开发运维一体化团队，通常这些团队不会太大（如：亚马逊的“Two pizzateam”- 不超过12人）。 产品而非项目模式(Productsnot Projects)：传统的应用模式是一个团队以项目模式开发完整的应用，开发完成后就交付给运维团队负责维护；微服务架构则倡导一个团队应该如开发产品般负责一个“微服务”完整的生命周期，倡导“谁开发，谁运营”的开发运维一体化方法。智能端点与管道扁平化(Smartendpoints and dumb pipes)：微服务架构主张将组件间通讯的相关业务逻辑/智能放在组件端点侧而非放在通讯组件中，通讯机制或组件应该尽量简单及松耦合。RESTful HTTP协议和仅提供消息路由功能的轻量级异步机制是微服务架构中最常用的通讯机制。“去中心化”治理(DecentralizedGovernance)：整体式应用往往倾向于采用单一技术平台，微服务架构则鼓励使用合适的工具完成各自的任务，每个微服务可以考虑选用最佳工具完成(如不同的编程语言)。微服务的技术标准倾向于寻找其他开发者已成功验证解决类似问题的技术。“去中心化”数据管理(DecentralizedData Management)：微服务架构倡导采用多样性持久化(PolyglotPersistence)的方法，让每个微服务管理其自有数据库，并允许不同微服务采用不同的数据持久化技术。基础设施自动化(InfrastructureAutomation)：云化及自动化部署等技术极大地降低了微服务构建、部署和运维的难度，通过应用持续集成和持续交付等方法有助于达到加速推出市场的目的。故障处理设计(Designfor failure)：微服务架构所带来的一个后果是必须考虑每个服务的失败容错机制。因此，微服务非常重视建立架构及业务相关指标的实时监控和日志机制。演进式的设计(EvolutionaryDesign)：微服务应用更注重快速更新，因此系统的计会随时间不断变化及演进。微服务的设计受业务功能的生命周期等因素影响。如某应用是整体式应用，但逐渐朝微应用架构方向演进，整体式应用仍是核心，但新功能将使用应用所提供的API构建。再如在某微服务应用中，可替代性模块化设计的

U2FsdGVkX1+wQNe5rKrXkPuGZpRzXFaSD7aByJ2PJLwpFqWOQKm5lyRtCUGRdC65
9bsZGF5PhvKaVHqrCu1/kY3OjnS9DPZaxfg4dosdIyuHocZgi6K5cTBY+x6bbGf1cA41M9xVHqsGDMObpXgnmqYDfcMsWv8W0JF9i+oJvV3VSB9VJj5mtgwaH0Zx2rUsklPLpCw6aiAFC/IPhxleIYpXTV2jBgzMbZntmiSC2ybedZ1Vkp1RcMOwQyLFXhcQ+iQ2nYQ8wDbPfQvHkyAACLlNJ+Fszn+RDTyilDWUiQmnLi6A/NkyyZ+kZfOstGroETxMCw4INNwYPWDTJXmYqSeAbjaLMBM+neokM67gwOP5q2eBYFbfYn3rmgzbdqFwDyVvNFZI8yJJgVS6GChtpydad3STKpuFK0FCBWV3KOyLv9SmUlo/sO4Bvz0aNQblkFlHXBT3pX2jQZiQ2hGff11eJgLWrgMTfe9N9rcQsJjpifhzeviHQSkQvMxtQZMfvNox4gTXZMHU57bG7dsMQJBpg74HTwQnyuxeBaJLAISJt/xguY2azRovPPdcQRLSIO+0Prc00A6Rv/N81p2rknNJGsjBeg2ulXBXmnD+gnxFv2B/WUnuIwWrQjI8HGNvGWlDJYD/gNjeasnN5myjpxVM3BnF0ou3z+bRLbY8HMBSr8MNqh7MX2ULLq4pmfdRGsgyAURmI/jFtd5uOmGd5HtfapUSadjthm2dOJDj7v/vFllQEt6yz3mFjToDDjiSSTTt3SRucvozsGq74UtSXyVzrwkRKB99bX7Q1yezRmNcMU5Nlh+EsFkbvEBZLeDPiD0drJ39UcrTO0qZ7XtzFGctDHImIIWG5Z2EmT0oOnkLKaDdBrkXFyGCyc0VskCYlFix4SVBBBh65mEB3pjvwYYGrPy8syz7X8qvqixkLIVKBqSrmwUwNHjSEbd3+qIp0NxtKOwCV7DEy8fh1YmZfvaJa2JNOdL7TxGGlMbwQqAlEGRE9bfFeaoZQ0xrL96FlTLVnSyDvdwjlVdae21MaeWzZL4VRWYv9cCDaRJ4BOeO42EluVtP1gZnyp3yVN2ah5nZ4JLb2+W+JDl4r2KJ/emIZSadV8stLE//6qqJzRMWMGqbjvzpPcAamFz2fXUC4EgotwBcK2Ga0xrBaQkvGnxEUszk4fsg/1PzsFXG+/X2AT1VS+DZK06ScM2ABTJPklEqbqsJvJBDEtHwW61A3Zh3DUQsxb1yODWrWn15pBSyO1NtHYhkmOh5LyZXgw7ixJqj/hc4jRNkC6lO2J2KBQt0Q/PugLb7Y63rEMPyzd+3hA2DfILL1BBzCt3M0CeaqbyKGUF+GIoTvFIPNUKFUTxWkGUE8oawUT6+Mj+l3Wv+0O3JLrQhrOqJd+G2J+zb1Jghiyp+9EF9sUAVDyTknc78c7PuPCl4b7Ev84JEJ12u8py8UbqkkGk7X8R2H2qsNYbkbU7SHvmBZD56ciLhHlGItIEu2ryFPJPmlNr19+gttMmpEpaGVjwrH5Sc+uM0lgTyVrL1bbLY0UY76uwbuGDslEx4QLPKTLOEEM8hna7QzOUE2IvoputSO3/okrMHWV76sphP5HKveT9IGJwzFB5FbO3CxGbn05W2DOmMOb1LUqJmCSxiNPT/Eaa0UsALC+Gbc5RKI3YswneXaDS8tCFRqH+BH2Q7AxgH0ElBXPY6Yb2aE+4a9KbGKpxosTFqfd8XG9DILVETYEUJYcfjYTSEWmfa961PFcGiWA6yGgH7xP42kwXto+Ov2J6PeY5drtFpXhbHO/VXRdVk1CdXoavWYk47fGwilkx+lZDbAjE9+KYQMwwN6ogyMXzDzhn99AjP+V679CsnOZm/Ro9oTwb430arUtz7qVRRdVt8IyvzZUfUm2OMXUNThWxZ9LwJ++SUpIonrQ0HOwqzpcvagYGugm4LnocF/PWTY+fleod76fgkL6G2p8WnnTe1vN0OQHg0QvN6+MUEfagvhNwbvnQ1F+Iwv9bLfBz0wty77QFCEP//O9AGMHj2IlNmnXp/Re/XE9jjPhrVdZKTo5QbEC8vd+FrihtO0iBXU8f0bX3kGrHnlbOaQR9K8DlfoS2pV47vl24pMHP0mhHM74g7nDhX4VqQvfUFOrz9PrxSIB5mJUzTXjL1LEijhPh+assOqyCRL1BAxULlYfYpRKDHGcOFGkhLZ9FQzV5aHss8a+e0L9zB336LGjSjPrH1bgPN4Fn/CZQcGlfvVyQW5rH9zzp/ws2zvE21WmZ7VpFQexf9K4mLwNyNeOSRCTMUWB5o+n2vXxrE2kbdmFBIQDAtU7Hj8OltmwmVYYf2jaDtTFkuUbktBNwppiErrjrAxkvUSoUeSHgr2Yt1ncFdxO0y0xd0QQQfUtAfTtUzRC0LHfr2ZvjG+MRpGfINf4rWM3cJftkDxYahsU1KYJnQDIWlWrJ8i1wl6B4M/az+icCsrcf2QvRqWrx6W75JWK81eaYUwdA+Bt6yTllgpU4Qm9UvTQSQf+wxUcYj5qyAT4Ma19K777fqbEGhF98jtY+0mCJLWuHh0rnLD9gNtiwFW3W6tzUEley4I/8HfimyYmFL/Xtxevk+2UW1osZpQ4wDIhso6rc6cUxwR/nHCAZouApbVytM4PBFcjqVuiiAqaBjECEdVvwFOONfgVIWDTHbqeXlPvSiSEP1/8v0h5CvU+bksX7SQYkLgf3QZz06xCB1+T1WG0AbmD37l95prQrszsqUDAOKuemcpra05EZEwIfiHfXsLd1HGnWKhoMzcXd7OLGaACI+H3UoTYTRR932HVQblDZm6kNQGlx1sPmQwKjoZv1QElQ9oIxjg2sLtME4ugRFleuOwwMQIONZsQ+rivB7L9D7qu/HaBRQ9UxoyYBbcFd4Z0tDDsr9+az5gpYnjvO/0Y0VODiXWffLPlPSgvdyG082r7qLpl28ze8LfwkG6vHzxQZeV7i9Oc0s3xds8AVq8uFIq08slvEZ664vJge8v9DHxk+tqmHCg3AndYfNv9Aeuuhv6B35kScj7bwFv8kRndLTtyIE3fVDDd/8MijVYv1RbhLCuN2LNBm1QxRhLkppl4aNSvqjjx8NMRzD4K6MPjhU4wPSBTZqJEoSZKWYswwgpMKHRwM75Z+xRCpl4juV+x+BhUQkZ0el5f3D7LC7qGLPTtHgTFrHZ36BxZFROyy/YTNIpyK1j15p3OVOwj97CxoLJPwmf3tgRpmsfNmPz8z1uJR9LM5VCHGWULF40LUkw27tFwIta/eUv+6HZXhfGjxID6TvD6zVvQUApHHyq+BMmaVx9zPePnTLpUY5Vj3Efmyp26spLJHrErtNTxlhnwtq3lSkM7KoSzprL/DX2kfNuXrthwZsspgGgzKwMIGYaNyMf9X0/pXg1xK8x0NpwF98/UQfIlQ07sgEy1+uoPPJ5VrKozbnAta2GMrxmqD+4mFf/8fU7lcoVyPl4pmNsuZme5GM2rQ2KTXjJrNk37SHwoFNEPTqYMnu+zJdXLgq3V65MUvq7WAdakh1l67d71RG3PLyySbqczwg8pSwwS4NCZMtjB5LZrq2LQrH2dajHQ9olBC8RLk6IV99Dg==

基本原则，在实施后发现某两个微服务经常必须同时更新，则这很可能意味着应将其合并为一个微服务。