本帖最后由 李白云 于 2017-10-31 22:56 编辑A: 对于问题的定界，可以使用微服务仪表盘，通过仪表盘可以看到系统内所有微服务及其实例的实时运行情况，找到没有正常工作的节点。找到问题节点后，可以通过APM查看问题节点的应用日志以分析具体问题。详细操作步骤可以参考APM服务使用说明。

本帖最后由 李白云 于 2017-10-31 23:00 编辑A: 这里提供两种部署方式，如下。 容器部署 请参考部署微服务。 VM部署 注意VM节点须安装配置JRE 1.8或以上环境。 步骤1 登录VM节点，执行以下命令创建临时目录。mkdir temp 步骤2 将编译微服务工程生成的部署包移入上一步骤新建的目录。部署包格式为target/temperature-1.0.0.zip。 步骤3 执行以下命令解压部署包。cd tempunzip temperature-1.0.0.zip -d temperature-1.0.0 步骤4 执行部署命令。cd temperature-1.0.0sh start.sh 步骤5 验证服务是否部署成功。 1. 查看运行日记、microservice.yaml监听端口，判断微服务是否正常运行。 netstat -nap | grep 12082 说明:端口可在microservice.yaml文件中配置，如下：rest: address: 0.0.0.0:12082 tcp 0 0 :::12082 :::* LISTEN 84477/java 2. 在“微服务目录”页面查看是否已存在部署的微服务。 ----结束

本帖最后由 李白云 于 2017-10-31 22:59 编辑A: 微服务是一种架构模式，其核心是将一个单体应用分成多个部分进行开发。所以微服务架构的应用程序，其本质上是一个分布式应用。基于微服务架构构建的应用程序，可以让业务变化更快，整体系统可靠性更高。 1. 在开发层面，每个微服务的体量相对较小，业界的two pizza团队和“2周即可全部重写全部代码”等都可以作为微服务划分的参考。在开发时期，需注意服务接口的定义以与周边微服务进行配合，“基于契约”的开发方式是非常推荐的。 2.在部署层面，微服务组成的应用系统通常比较复杂，在一次性部署的时候，需要进行编排部署。微服务的运维与传统应用相比，在原来的指标监控、日志收集之外还非常强调治理。其核心理念是在运行时期通过对线上系统的各种调整以达到系统整体健康度最佳的效果。

本帖最后由 李白云 于 2017-10-31 22:59 编辑A: “微服务引擎”是华为公有云上的服务，提供了对微服务运行时期的支持，让用户只需聚焦在对自己业务的运维。而其开发框架ServiceComb不与华为公有云绑定，甚至完全开源。用户可以在线下开发微服务并运行在包括本地环境在内的各种环境中。公有云上提供的开发框架在ServiceComb的基础上提供一些商用特性，该部分不开源但是可以免费使用。使用CSE Java SDK进行微服务开发，可以参考《开发指南》的相应章节，进行本地开发。

本帖最后由 李白云 于 2017-10-31 22:58 编辑A:CSE充分借鉴华为公司内部多个大型系统微服务化的构建经验，将多年来对企业级应 用微服务化过程中积累的最佳实践都构建其中，成熟稳定，降低了企业级应用微服务 化的门槛。 在云上使用CSE微服务引擎，用户无需关心自己业务之外的微服务基础设施，保证系 统整体稳定性。同时微服务部署即用，管理、治理全部开箱即用，还可以获得开发时 期的指导和帮助，以及后续技术发展的最新信息。

本帖最后由 李白云 于 2017-10-31 23:08 编辑转载自：https://mp.weixin.qq.com/s/LFIgJCljF9zKeGt_VfPN4g 微服务在 2016 年成为仅次于物联网和认知计算的第三热门技术，微服务究竟有何等神通，让业界的互联网和 IT 巨头们趋之若鹜？ 传统应用之殇 版本发布 · 千年等一回 在过去传统企业应用开发模式下，每当遇到需求要修改时，不得不按照大颗粒系统发布版本，瀑布式的版本计划困住了程序员那优雅的双手。 应用升级 · 祝你平安 应用无法做到永远在线，大版本升级时，不得不停机中断服务。一个小小的问题就有可能带来整个系统的崩溃。 技术选型 · 独角戏 技术实现单一，需要想办法用一种技术解决所有问题。每个问题都变成钉子，每个方案都被当成锤子。 微服务 · 初见 如何解决传统应用开发模式逐渐暴露出来的牢骚？随着领域驱动设计、持续交付、按需虚拟化、基础设施自动化、小型自治团队等实践的流行，微服务架构逐渐地被广大勤劳智慧的架构师们归纳总结而出： 微服务架构风格，描述的是一个大型复杂软件应用系统由若干个微服务组成。系统中的各个微服务能被独立部署和扩展，每个微服务还能提供一个稳固的模块边界。各个微服务之间是松耦合的，微服务很小，专注于做好一件事情。微服务框架带了良好的技术异构性、弹性、扩展性，它的简化部署为持续交付提供了巨大推动力。 微服务 · 爱你在心口难开 事实是大量传统应用的微服务改造过程并没有想象的那么顺滑，虽然微服务带来的好处多多，但同时也引入了很多新的挑战，如： [*]分布式编程难度大、有风险：分布式编程难度更大，远程调用更慢且总存在失败的风险 [*]需处理分布式系统的一致性：对分布式系统来说，保持一致性非常困难，意味大家都要处理最终一致性 [*]增加运维复杂性：需要一个成熟的团队（机制）来管理大量需要频繁部署的服务 那么，是否该用微服务架构？什么时候用微服务架构？该用什么样的微服务架构？怎么用微服务架构？遗留业务如何快速迁移上云？微服务化之后繁杂的微服务如何管理运维？ 微服务 · 多了“引擎” 两个字 如何解决以上问题？ 你也许希望有一个开发框架，能够帮助各企业和开发者最大化的降低应用微服务化的门槛。 你也许希望有一些工具，能够有力支撑企业在微服务架构下的高效开发。 你也许希望有一个平台，能够帮助企业和开发者全方位管理改造后的大量微服务。 你也许希望有一位领先微服务改造专家，能够给予专业的微服务化解决方案指导。 微服务引擎 CSE 是全新的企业级微服务开发与管理平台，包含了微服务 SDK、一系列配套的开发工具以及一站式微服务应用管理平台，致力于为企业提供 0 门槛服务化改造，为企业提供微服务全生命周期管理服务。在 CSE 上线之前，先让我们露出一小部分核心性感的特性刷新你的微服务观。 1、开放是一种人生境界 CSE 支持多开发模式多语言多协议，传统应用改造 0 门槛。无论遗留应用是 SpringMVC、透明代理、亦或是 JAX-RS 的开发模式，业务代码 0 改动就可以完成微服务改造。无论你是倾心 GO 语言还是青睐 JAVA，无论你是执着 REST 协议还是钟情 RPC，没有做不到，只有你想不到。同时，CSE-SDK 还兼容 spring-cloud 主流社区，保持与业界生态能力互通。 2、用一杯咖啡的时间完成微服务改造 CSE 黑科技助力传统应用 0 修改服务化。当然开发者可能已经写好了一些微服务或者真的一丁点儿都不想改动遗留代码。CSE 提供了一项黑科技，支持非侵入接入微服务治理。给你一个微服务摇篮，让遗留应用无缝接入 CSE 微服务治理与管控平台，让你的应用安全可靠舒心。 3、周末再也不想接到加班电话？ 一站式微服务应用管理云服务，服务论剑随时随地：在微服务开发完毕之后，繁杂的微服务实例如何管理、如何监控、如何运维？微服务引擎的一站式微服务应用管理平台，提供微服务全生命周期管理，提供微服务治理、微服务安全管理、灰度发布、分布式事务等等特性。让你享受谈笑间樯橹灰飞烟灭的商业快感！ 微服务引擎即将在11月份震撼上线，欲知更多精彩预告请狂刷社区。 PS：我们还有专业的微服务解决方案团队，提供一站式解决方案支持哦！

本帖最后由 码小玩 于 2017-10-11 15:17 编辑软件架构是软件的生命，活力和骨架，它随着时间而成长和演化，不变的软件架构是一具僵尸而已。《设计之美》提到，无情的重构，架构就会产生。而这种架构成长的动力在哪里？其动力就在于业务的增长，一切不为业务服务的架构演化都是耍流氓！ 本文将从作者多年的实践经验出发，解读什么是架构和业务，微服务架构，以及架构演化如何促进业务增长，文章还阐述了架构师这一角色如何处理复杂问题。 2684 什么是架构和业务大师Grady Booch将软件架构解释为架构是一种设计，但并非所有设计都是架构。架构代表着发展一个系统的重要决定，而这种重要性是通过引入变化的成本来衡量的。 有一本书叫做《恰如其分的软件架构》Just Enough Software Architecture（A Risk-Driven Approach），里面有一种观点，就是对于特定的一个系统，需要做多少相应的架构设计工作呢？如果设计工作容易开展，风险小，也许不需要太多架构投入；如果设计工作风险大，牵一发而动全身，那么就需要加大架构的规划。 引入变化成本将成为架构决策的重要因素，这与我的想法不谋而合，其实架构的演化是与业务息息相关的。所谓业务，从经济学来说，就是利润＝收入－成本，那么架构在演化的时候必须尊重这个基本法则。架构的核心目标是支持业务，增加收入，降低成本，减少费用。 互联网软件的架构大部分都是从三层结构开始的:前端、业务逻辑层、数据库。这可能是大部门业务在初创阶段需要的，为啥这种结构？这是一种解耦，将变化快、中、慢三个层次的模块分为三个部分。前端变化最快，独立起来，中间业务逻辑变化次之，数据层相对稳定。 这样不同速度的变化，可以在自己的赛道上按自己的节奏走。另外一个重要原因是Conway法则，软件的架构总是和组织结构有关，工程师很容易分成前端工程师，服务端工程师和数据库DBA。 软件架构的演化那么三层结构是否就无敌了么？在实践工程中，三层结构也不少烦恼，例如通常一个需求会涉及到几个层次的修改，而这种修改需要分散在不同的工程角色中，那么协调的成本很高，排期的过程也要服从木桶原理，最慢的工序将决定最后的发布时间。各个层次的耦合越来越多，越来越繁杂。 举个例子，逻辑层为了加快访问速度，会引入Cache层，这样数据就可能分布在Cache里，或者数据库层。另外，业务层的数据来源可能不全部来源于数据库，很多来源于离线的数据处理脚本，这些数据通常会存放在NoSQL中，例如Redis，HBase等。再进一步发展就是，各个业务使用NoSQL的模式也不一样，有的业务数据量巨大，访问延迟很慢，有的只是配置文件，需要实时更新。随着业务发展，业务层开始使用其他第三方的服务，通过服务接口获取数据。最后，这就慢慢形成了一个网状的服务依赖和数据依赖。 慢慢的，简单的三层结构渐渐堕落成无序的网状结构了。对于网状结构的初期，线上特别容易出问题，容易造成雪崩效应，一个模块的变化容易改变整个系统的服务能力（如果你的架构没有出现过这个问题，也许说明你的业务发展的不够快，不够复杂）。在流量增长迅猛的时候，大家会被迫忙于解决线上问题，架构师也开始谋划架构的长期演化。 很多同学会说，为啥不早早就把架构规划好呢？能够早早把架构规划化，无忧无虑的开发公司估计都破产了，举例来说，有些电商公司在发展初期，对于是做平台还是做服务常常是争论不休的，这样适合的架构也不容易落地的。京东从ASP.NET转向Java，从面向技术的架构转型为面向业务的架构，都是适合业务自发展的需求，从技术角度来看并非是最理想的解决方案。 人们对于过多的层次理解总是有限，一般人对于超过3层的结构，基本就糊里糊涂了，比如说OSI定义了7层结构，但是最流行的确实是TCP/IP的4层结构；J2EE定义的层次复杂性吓的很多创业人，敬而远之，这就是一些轻量级的Spring等框架大行其道；MFC类的继承关系超过3层，开发者基本上就找不到北了，目前还有很多讨论。因此，对于架构的设计，应该服从简单的原则。 解耦是架构演化的核心问题 按照业务进行系统切分是必须经过的一个过程，分而治之，独立自由发展，这也是业务快速发展初期的必由之路。解耦通常是很痛苦的一个过程。 解耦有很多方式，通常采用以下的一些技术： 最通常的是引入队列，通过生产者和消费者模式，减少两个模块的耦合度。 通过反转注入IOC，通过配置定义不同的实现。 采用事件驱动的设计模式，包括观察者模式，消息链模式等。 解耦之后，整个系统会清爽很多，代码结构会变得很清楚，处女座的同学可以开心一阵子了。解耦可以帮助处理部分的性能问题，特别是异步化的调用。但是，解耦并没有解决各个模块的扩容问题。解耦只是以前缠在一起的问题，解开在不同的独立服务和服务之间的连接中。例如，在通过Kafka队列解耦过程中，队列堆积是经常碰到的问题，如何从监控，控流，容错等方面，改进碰到的问题就是解耦后面首要解决的问题。 在扩容的过程中，会碰到很多瓶颈，这些瓶颈往往是一个接一个的出来，就像打地鼠一样，打死一个，出来一个，打死两个，出来一对。当然，前提是业务的高速发展。 处理架构的瓶颈如何处理扩容问题，核心是找到系统的瓶颈，常见的瓶颈包括下面的情况： ● 5.1 数据写瓶颈 内存先做聚合，到一定量后统一写入数据； 采用NoSQL技术； 水平分库和垂直分库。 ● 5.2 计算瓶颈 计算瓶颈经常出现在复杂数学模型的计算，随着Features的增多，计算时间变长。计算瓶颈通常需要自定义解决方案，例如内存换时间，分布式计算，分级服务。例如在搜索引擎中，对于商业性潜力大的查询，可以花费更多的计算。对于长尾词，可以减少计算的层次，以达到节省计算的成本。 ● 5.3 存储瓶颈 存储成本几乎是每一个爆发性增长业务都要碰到了，存储包括日志，图片和数据等。存储通常分布在内存，缓存，SSD，磁盘等地方。内存不够用是常见的最大问题，内存通常都被数据塞满了，分布式NoSQL通常是实用的解决方案，如果数据还是大，那么可能需要做索引，可以使用Elastics Search，Lucence等。 现代软件的架构SOA 谈到架构，我们都会提到SOA，这是一个老话题，到底什么是面向服务的架构？SOA是通过分布式的服务模块来构建软件系统，服务之间通过接口契约联系起来，而避免了不同模块之间采用不同的方式交换数据，例如文件交换，内存共享，数据库直连等方式。这种方式改善了封装，复用和解耦等方面，适用于复杂的大规模系统。 SOA的第一批实现基本都是企业级别的，例如Java 的ESB(企业服务总线），实现过于笨重，部署过于复杂。与此同时，各个互联网企业也基于SOA进行大量开发工作，也积累了很多SOA，特别是分布式的经验。 为了加快SOA的开发节奏，充分利用云部署的架构进行水平扩展，一种轻量级的SOA方法正在慢慢的流行起来,这就是微服务。 微服务化的趋势 微服务是组织和利用分布式能力的一种模式，微服务提供一个高性能的服务接口，是进程之上的一种模式。提供独立的业务能力,特别强调的是，独立的业务能力；微服务是用一组服务来构建应用，服务独立部署在不同进程中，不同服务通过轻量级的交互来通信，例如RPC，HTTP，服务可独立扩展和伸缩，每个服务定义了明确的边界，独立团队来维护。 微服务特征包括以下8个方面：组件化； 业务组织团队； 服务就是产品； 去中心化； 基础设施自动化； 容错设计； 计划设计； 服务质量保证。 架构的角色篇虽然对于软件架构的技术有很多研究、发展、创新，但对于架构师这个角色却缺少经验，例如对于公司是否需要专职架构师有多种不同意见。很多公司的架构师实际上是开发经理或者研发总监担当，因为架构师直接带领团队，因此架构演化执行的效率高。 但是也有很多公司（例如微软）的架构师是一个IC角色，换句话说他们需要靠自己的影响力推动架构演化和升级，而开发经理更加直接面对业务需求，这个时候短期业务开发和架构长期演化需要在不同的角色中达到平衡。 这种不同实践的核心问题是“对定一个系统，需要多少专门的架构设计工作？”一个关键问题是，如果一个项目没有太多的设计风险，说明架构在一个好的状态，不需要太多的架构工作；如果一个系统的设计风险很大，每一个业务实现都需要过多的考虑设计风险，那么说明这个项目的架构需要大力投入了。这就是风险驱动的架构设计。 架构师如何处理复杂问题架构师在面对复杂问题时，像很多人一样，首先收集足够多的数据，将问题描述清楚，抽象来说，架构师处理复杂问题的三种基本方法：分解（分而治之）、抽象（大象无形）、知识库（见多识广）。 分解通常是按照一定的角度对系统进行拆分，角度通常是按照业务、功能和团队等方式来做。举例来说，如果是国内和国外的合作项目，尽量会选择没有减少依赖的方式来拆分和项目管理。分解之后的联系通常使用简单、可靠的接口来定义，包括SLA等。 抽象是屏蔽了细节的一种方式，就像大象无形，很多人真正把架构问题想透以后，抽象到最简单和基本的问题，就容易推动架构的演化。举一个例子，飞机是非常复杂的，但是如果将飞机制造抽象成物理部件系统、空调系统、机电系统、光电系统，等等，那么理解起来的难度就会降低很多。 利用知识库也是架构师重要的技能，利用互联网快速找到相关的信息，多学习学习别人走过的路，踩过的坑。早年的软件工程所强调的领域工程，也是希望通过工程化的方式，把已经有的行业知识积累起来，为他人所用。 目标已经有了，下面就看行动了！记住：学习永远是自己的事情，你不学时间也不会多，你学了有时候却能够使用自己学到的知识换得更多自由自在的美好时光！时间是生命的基本组成部分，也是万物存在的根本尺度，我们的时间在那里我们的生活就在那里！我们价值也将在那里提升或消弭！Java程序员，加油吧