微服务架构应用实践

   <p>随着Docker等云技术的大量应用，企业的互联网业务复杂度不断提升，传统整体应用架构模式越来越臃肿，难以适应灵活多变的业务需求。微服务架构（Microservices Architecture）应运而生，它放弃了传统大规模的单块集成应用，改为细粒度、松耦合、可灵活组合的自治单元，成为云计算时代应用的主要构建方式。</p>    <p>微服务架构以其高度的弹性、灵活性和效率的巨大提升，快速受到各领域架构师和技术决策者的关注，在Netflix、Amazon、Airbnb等公司成功应用，并逐渐成为互联网行业最受关注的技术架构。今天就由云智慧开发经理 Allen Lai为大家带来关于Microservices Architecture微服务架构应用实践的分享内容。</p>    <p><strong>什么是微服务？</strong></p>    <p>微服务是一种全新的互联网架构，它的基本理念是将一个肥大的系统拆分成若干小的服务组件，组件之间的通讯采用轻量的协议完成，譬如REST API。微服务本质上是SOA (Serviceoriented Architecture) 的扩展延伸。相对来说，微服务的可操作性更强，可以逐步安排合理资源，对一个大的系统进行分解，或是至少停止让它继续肥大。</p>    <p><strong>微服务的好处包括：</strong></p>    <ul>     <li> <p>按照业务功能的独立垂直开发机制；</p> </li>     <li> <p>异构开发语言，更多的技术选择；</p> </li>     <li> <p>高效的部署机制(自动化部署) 和尽可能短的部署周期；</p> </li>     <li> <p>高效的测试机制，易于构建基于服务接口的自动化测试，能尽可能早的发现问题；</p> </li>     <li> <p>面对下游消费者透明，如采用Swagger，可详细描述输入，输出标准(见下图)。</p> </li>    </ul>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/e1d91dae52751047fb252ece7cde8611.jpg"></p>    <p><img src="https://simg.open-open.com/show/5200efc57802b5752f735a18a62e85f5.jpg"></p>    <p>Restful API集成Swagger1</p>    <p><strong>整体应用 vs 微服务应用</strong></p>    <p>那么，我们来看看另一种过去常用的架构，单体架构Monolithic application的情况，单体架构也有它的优势，对于项目应用或是公司创业初期是个很好的选择，可以更快的解决有和没有的问题，适合小团队开发实现，而且横向扩展方便，例如镜像部署的时候。但当公司大了以后，随着应用越来越多、第三方系统的不断接入或者企业的并购，问题会慢慢的暴露出来。</p>    <p>主要体现在如下方面:</p>    <ul>     <li> <p>功能多了，应用肥大；</p> </li>     <li> <p>接口污染，jar包冲突；</p> </li>     <li> <p>部署困难，任何修改都需部署整体，带来整体服务downtime；</p> </li>     <li> <p>测试/检查比较困难，任何修改，切入点过于依赖于从前到后的测试；</p> </li>     <li> <p>问题定位困难，不易找到具体的问题点，通常需要从前到后筛查，或者从海量的og里筛查；</p> </li>     <li> <p>某个服务出现OOM后对整体应用产生影响；</p> </li>     <li> <p>无法通过具体服务对资源的需求搭配硬件资源/网络资源，只能安装最高需求整体满足；</p> </li>     <li> <p>新进人员对开发环境搭建，应用的熟悉需要很长的时间，很难快速通过以点及面的方式切入系统。</p> </li>    </ul>    <p>我曾经遇到过一个超过400M的大Jar包，启动应用超过5分钟，那段时间简直被OPS骂死。举个例子，一个产品犹如一条鱼，开始的时候游得很畅快，但是有一天，这条鱼变成这样：</p>    <p><img src="https://simg.open-open.com/show/b801a4efbb51c3487350449b731d3ab6.jpg"></p>    <p><strong>整体应用架构</strong></p>    <p>它每次的转身、变更都很慢，因为太重了。后来我们意识到，不能再往它身上放东西了，经过逐步的调整，变成了如下的结构：</p>    <p style="text-align: center;"><img src="https://simg.open-open.com/show/62d802afe987e84fb6e3557cf5145ac0.jpg"></p>    <p><strong>Microservices Architecture</strong></p>    <p>Tomcat上承载的东西变少了，有明确边界的服务都被拆分成了独立的restful应用，这样面向众多客户的web app，部署节奏加快，后端的若干子服务部署节奏也加快。</p>    <p>公司大了以后，异构系统和Hybrid都是在所难免的，有朝一日 云智慧 也会面临这个场景。 监控宝和透视宝 平台提供的功能由php, java, Ruby on Rails, Python Django, .net mvc等组成，同时对于外部服务的集成，集成后对主应用的影响不亚于功能性的要求。比如集成一个外部服务，他的服务升级很快，那么对这块功能的变更和主应用应该是隔离的，而微服务架构确实能隔离这个问题。</p>    <p>微服务架构的实现，目前国内有阿里的dubbo，国外有推ter的Finagle框架，他们都是基于RPC的。如果我们的微服务是基于restful服务，那么无须选择他们，考虑到异构系统，基于http rest依旧是最合适方案。</p>    <p>任何一种架构都有它的适用场景和一些不足，微服务什么问题呢？</p>    <ul>     <li> <p>需考虑服务间通讯的局部不可用问题。</p> <p>假如一个请求需要2个或者多个服务共同组装数据，某个服务不可用，本质上这个应该取决于业务，具体该请求判决为成功或失败取决于该故障服务提供的数据权重，比如一个提供商品评论的服务暂时不可用，该数据是次要的。</p> </li>     <li> <p>服务线性依赖问题</p> <p>这是个设计问题，从设计上微服务不应该依赖别的业务微服务，如果设计成了服务A—>服务B>服务C..那么带来的问题会较多。</p> </li>     <li> <p>带来更多的单点考虑</p> <p>采用合理的负载均衡可以解决，但是显然会带来部署的复杂性。</p> </li>     <li> <p>应用管理复杂度会上升</p> </li>    </ul>    <p>这方面，业界也有解决方案，比如Docker / Kubernetes集群化方案。今晚主要是从High level介绍一下微服务架构，具体细节要有合适的应用场景，下次分享我们会准备一个Demo，一起来尝试如何让web app更轻，如何用spring boot构建一个微服务。</p>    <p style="text-align:center"> </p>    <p> </p>    <p>来自：https://mp.weixin.qq.com/s/MGA45XfcBGPF5vtUijU7ug</p>    <p> </p>