乐豆玩用户登录还没账号？
使用其他方式登录：
体验周期：日起
更新周期：每周一发放
目前更新至：3月20日
厂家信息：PPmoney互联网金融平台（）由广州万惠投资管理有限公司负责运营，经营团队由金融服务、风险管理及电子商务等业界一流的专业人士组成。PPmoney以人民（People）财富（money）惠人民（People）为宗旨，致力于为公众提供一个安全、专业、高收益的理财平台。PPmoney结合多年的资产管理服务和风险控制经验，利用先进的信息处理技术，不断为平台用户提供更丰富、更便捷的互联网理财产品。
投资攻略：预计年化收益：7.5%~25.00%；起投金额：100元起；投资期限：15天及以上标（详情请查看PPmoney官网）
1、完成体验后，请尽快回本页面刷新页面后提交正确的信息；
2、提交信息请保持与注册信息一致性，不一样审核不通过；
3、招募满后不能提交；
4、提交有误将无法修改和获取奖励；
5、手机注册成功后，一周内回访方可有效；
手机注册成功（一周内接电话方为有效）
首次投资100元（15天及以上标）
首次投资500元（15天及以上标）
首次投资1000元（15天及以上标）
首次投资5000元（15天及以上标）
首次投资1万元及以上（15天及以上标）
1、点击“立即体验”进入PPmoney注册页面；
2、输入用户名、密码，点击“注册领取588元现金”即可注册
3、获取手机验证码认证手机号
4、点击“投资理财”，选择需要投资的项目点击“立即投资”
5、输入投资金额，点击“立即投资”即可
6、返回乐豆玩页面提交信息，待审核通过后，自行领取奖励；
*在体验过程中如有以下违规行为，将得不到乐豆奖励，严重者直接冻结帐号：
1、创建的账号、昵称不得跟乐豆玩内容相关，更不得胡乱填写注册信息。
2、不得在商家平台里发表任何有关乐豆玩的话题，如“乐豆玩体验、赚乐豆”等。
3、不得在商家平台里发表诋毁商家的言论，如“垃圾网站、渣渣网站”等。
4、不得为了快速获取乐豆奖励，使用第三方软件；
5、不得注册多个乐豆玩账号参与同一体验任务；
6、不得在体验任务的同时帮助其他好友代玩同一个体验任务。
7、不得在商家平台内发布乐豆玩推广链接拉人，以免对商家造成影响。
8、部分任务需电话回访，可回复：以后会继续关注和投资。若回答只是为了任务而注册，或者空号，停机，拒接等，一律无效！
9、由于商家原因导致用户利益受损，乐豆玩有义务协助用户进行维权，但无赔偿责任。
*在体验过程中请注意以下几点，防止数据不更新：
1、投资前请仔细阅读页面内温馨提示信息，以免出现奖励无法领取的情况；
2、完成体验后需回本页面提交体验信息，信息错误将可能导致无法获得奖励；
3、更新周期是商家约定返回数据的周期，但如遇特殊情况，商家可能延迟返回，具体请以已更新时间为准；
4、请勿在体验过程中点击其他网页！也不要自行百度搜索后注册体验；
5、请尽量在注册当天完成投资，否则易追溯不到数据，可能会无法获得奖励；
乐豆玩体验任务注册
您正在注册PPmoney理财-红包雨来临任务
注册完成后请在本页“体验任务”查看注册详情
温馨提示：若不显示注册信息，请更换浏览器清除cookies重新注册PPmoney这次开始玩大的
　作者: 肖授　编辑:
　　【IT168厂商动态】“自贸区“、“互联网+”，这两者聚集在一起会开出多么美妙的果实?随着4月21日中国广东、福建、天津三大自贸区同时揭牌，这一美好愿景开始逐渐变为现实。对于中国互联网金融领先企业PPmoney来说，落户家门口的自贸区不仅在发展政策给平台带来了优先扶持的发展动力，而且在金融资产来源上提供了更为丰富巨大的运营空间，无疑为平台今后的高速提升提供了重要法码。　　(21日上午10时，广东自贸试验区挂牌仪式在广州南沙举行)　　互联网金融喜迎双重国家级战略利好　　“互联网+”在今年两会期间被提升为国家战略，处在风口的互联网金融借助这一战略将会迎来更为光明的前景，将更好地帮助解决“两多两难”问题，助力实体经济转型。广东、福建、天津自贸区在今天同时挂牌，并把金融创新作为发展的重点，“自贸区”这项国家战略将和“互联网+”共同促进互联网金融的发展。　　广东自贸区的定位是依托港澳、服务内地、面向世界，将自贸试验区建设成为粤港澳深度合作示范区、21世纪海上丝绸之路重要枢纽和全国新一轮改革开放先行地。在这一战略定位下，广州南沙、深圳前海、珠海横琴片区无一例外地把金融业作为发展的重点之一，互联网金融、商业保理、融资租赁等新的金融业态愈发引人关注。　　在4月21日广东自贸区揭牌仪式的现场，广东省省长朱小丹指出，广东自贸区将强化国际金融贸易航运功能集成，着力在自贸区发展新的金融业态、贸易业态、航运业态，为珠三角制造业提供高质量的服务，促进实体经济转型升级。　　广东省省长朱小丹在挂牌仪式上致辞　　由此可见，不断进行金融改革创新、切实服务制造业为主的中小微企业、促进实体经济转型升级将有助于广东自贸区当好改革开放排头兵，成为创新发展的先行者。　　前来出席揭牌仪式的PPmoney互联网金融平台董事长陈宝国对记者表示，平台这两天双喜临门，4月20日平台累计成交量突破100亿元关口，正式跻身国内互联网金融界的“百亿俱乐部”;今天广东自贸区揭牌对平台的发展更是意味深远。陈宝国说，“广东自贸区着力发展新的金融业态，PPmoney将积极在自贸区内抢滩登陆，拥抱更为广阔的发展机遇。”　　PPmoney正式瞄准国际化融租与保理业务　　环顾中国互联网金融业，PPmoney目前已经成为业内非标资产证券化的标杆，平台积极抢滩自贸区并非一时兴起，而是基于打通民间金融四大门类的迫切需求。　　广东省省长朱小丹(右一)同陈宝国亲切交谈　　商业保理、小贷以及典当业务是目前我国民间金融中除融资租赁业务之外的三个主要子类，PPmoney针对这三种业务分别开发出了“加多保”、“安稳盈”以及“典当宝”三款互联网金融产品，受到了投资者的普遍欢迎。在陈宝国看来，眼下自贸区拥有得天独厚的政策便利和发展机遇，PPmoney未来有必要切入融资租赁业务，这是一个超过3万亿的蓝海市场，目前公司数量超过2000家。　　令人印象深刻的是，2015年1月份，李克强总理视察广东自贸区南沙片区时曾提出，要简化审批流程，降低准入门槛，释放市场活力，促进公平竞争。业内普遍认为，这将为融资租赁业务的发展再添一把火。　　“我们会积极响应李总理的呼吁，努力践行金融创新，不断探索互联网金融与融资租赁业务合作的新思路和新模式。在互联网金融联姻融资租赁相业务方面，公司已经迈出了实质性的一 步。”陈宝国透露，除了继续深挖商业保理、小贷、典当等民间金融业务的市场潜力外，PPmoney将把业务触角伸入国际保理、融资租赁等更多方兴未艾的细分领域，积极打造民间金融的全链条服务模式。　　(PPmoney董事长陈宝国陪同省委省政府领导参观自贸区)　　随着业务触角从小贷、典当涉足到国际保理、融资租赁等规模更大、潜力更深的领域，PPmoney互联网金融平台的发展视野更加国际化，平台始终坚持的产品为王的发展思路未来将有助于公司业务规模、发展质量提升到一个新的台阶，登陆资本市场的前景颇为乐观。　　陈宝国透露，平台最近在积极筹划登陆资本市场，特别是国内的沪深两大交易所，目前监管层已经释放出了积极的信号，证监会对有实力的互联网金融企业发出了邀请，PPmoney一定会不断努力，力争成为国内首批登录A股市场的互联网金融企业。
IT168企业级本文来自来自中生代技术群的36期分享，介绍了为什么要选择微服务架构，PPmoney微服务框架的技术选型，介绍微服务生态中的支撑体系以及旧有系统的迁移改造。
大家晚上好，今天给大家分享的内容是 PPmoney 微服务之路。
首先简单介绍一下，我是来自 ppmoney 的资深架构师 敖小剑，目前负责 ppmoney 的基础架构和服务化推进。
今天分享的内容主要有四个部分：
首先，介绍了一下为什么要选择微服务架构
其次，讲一下我们微服务框架的技术选型
第三，介绍微服务生态中的支撑体系
第四，旧有系统的迁移改造
第一部分 为什么要选择微服务架构
我们先开始第一部分的内容：为什么要选择微服务架构？
先简单介绍一下我们公司——PPmoney(万惠).
4年做到600亿元，企业可以说是 野蛮生长。在快速发展的同时，沉积的问题也很多。
大多数创业公司在初期技术上是很郁闷的，没有足够的技术基础，所以早期技术栈会呈现多样化。造成多样化的原因，首先是“黑猫白猫，能上线就是好猫”：只要能把代码写出来、能上线，就OK；第二个是怎么快怎么来？包括买,比如淘宝第一个版本。
问题随即暴露，规划不足、实施艰难；需求太多，来不及规划；变更太快，规划跟不上；还有非技术的原因比如人员变动频繁。整个野蛮生长的过程中，技术债务会越来越多，开发成本会越来越高。现在在加新的功能，会比想象中的要难得多。而且，最严重的是出现了“恶性循环”。
而对于互联网金融企业，应对市场的速度必须要足够快，否则难于立足。
如漫画中所示，我们出现几个问题：
方法不得当，开发效率非常低，
问题积累，工程师不堪重负
没有时间改进，咬牙硬扛
即使给工程师现成的改进方案，他也会拒绝接受：我们很忙，我们没有时间。
这是一个令人心酸的局面，双方都很无奈。
我们改进的方向:
首先事情要规范化，让无序的开发变成有序。无序的开发是什么概念？逮到哪就做到哪，至于用什么技术：有什么人用什么，会什么用什么。有序的开发有很重要的事情，叫做“统一”，同时简化技术栈。
第二个就是要“可重用”。之前的项目都是从头开始或者是从上一个项目里头复制过来，这里面是有很多事情没有做好的：基础类库、基础设施、基础架构。做这些最终的目标是提升大家的项目起点，所谓"不要输在起跑线上"。
第三个是“敏捷”。这个东西对我们而言做得非常不好，现在基本上是属于没有的状态。虽然各个团队都在宣称敏捷，但是实际做的不太好。
第四个就是“自动化”。这个就是我们希望能改进的一个重点，包括自动化测试、自动化部署、云技术、容器化等，解决这个问题的最终的目标：摆脱低级重复。
DevOps和每日发布是我们的最终目标，虽然从目前看差距还非常大。
我们最终的选择是推行服务化，以微服务架构为目标进行技术转型。
微服务的概念和好处这里就不展开。
第二部分 dolphin 微服务框架的技术选型
接下来我们开始第二部分的内容，讲一下我们微服务框架的技术选型。
这是 PPmoney 自行开发的微服务框架，海豚，英文名 Dolphin。希望这个框架做的敏捷、轻快、优雅，就像海豚一样。
开发工作从今年3月份刚开始，目前版本到了 0.7.*，已经在线上跑了。另外后面会提到，我们最重要的一个大系统已经基于这个框架做了重构(或者说重写)，即将在10月上线。
我们的小目标：打造业界一流的微服务框架。
Dolphin要打通整个业务的全流程，这个可能是跟其他微服务框架极为不同，这也是我们技术选型的一个重要的基石。
通常来说的微服务框架覆盖的都是服务器端，不同的的服务器之间的调用。但是这里我们会有一个非常重要的需求，我们必须要把手机App覆盖到。为什么要加这个需求？一个简单的数字足以说明：目前80%成交额来自于手机App。因此我们除了考虑服务器端之外，要考虑从手机App到服务器端的数据通讯。
我们希望它能覆盖日常的开发场景，包括手机App开发、Web服务器开发、应用服务。另外要实现的一个目标就是要三位一体，也就是上面这句话，“打通开发、测试、运维三条线”，实现整个流程的畅通，最终实现全程自动化。
我们看一下Dolphin的主要技术栈：
Google开源的gRPC框架，支持多平台多语言，最大的优点是支持手机App。
SpringBoot，Spring团队集大成之做，口碑非常好，好用易上手。
Etcd3，号才发布，够新鲜，主要用于服务发现和配置
首先介绍一下gPRC。这是 google 新推出来的 RPC 框架，今年8月才发布的 1.0 正式版。gPRC 的主要特性：
Protocol Buffer 3.0：最重要的改进就是可以支持 iOS 和 android
HTTP/2 协议：出来有几年了，目前正在慢慢铺开
netty 4.1：提供NIO支持和 HTTP/2支持，也是今年6月才刚发布的正式版本
对Android/iOS的支持，这对我们来说是杀手锏级的特性
gPRC 的主要特性：
有两个特性对我们来说特别的重要：
多路复用，可以全双工发送请求和接收应答，不再需要连接池，即使几万 QPS 也是可以一条 socket 搞定。
支持流/stream，在流的基础上实现了Server Push，方便做变更通知，不再需要客户端做费力的 Long Pull。
google 给 gRPC 的地位中就明确提出：将移动和HTTP/2 放在首位。刚好契合我们的需求，因此成为我们dolphin微服务框架中最重要的一个技术选型目标。
我们选择了 Spring Boot 作为微服务框架的基石，这也是业界常见做法。暂时没有选择 spring cloud，主要是技术选项和我们差异比较大。
在3月份我们做技术选项时，在 zookeeper，etcd， consul 之间我们最后选择了 consul。但是在7月1日 etcd 的 3.0 版本发布之后，我们决定将 consul 替换为 etcd 3.0。
因为我们觉得 Etcd3 更适合 Dolophin 框架。注意我说的是更适合，不是说 etcd3 更好。
使用 etcd3 替代 consul 的几个理由：
统一通讯协议：新发布的 Etcd3 给了我们一个很大的惊喜：它的通讯机制改了，Etcd3 改用 gRPC 作为通讯机制，替代原有的rest。因为 Dolphin 框架也是使用 gRPC，因此改用 etcd3 替代 consul 之后就简化了内部通讯机制，都统一为 gRPC 了。
减少依赖：不用 consul 之后从而也省掉了 consul client 端引入的一大堆的用来实现 rest 和 long pull 的依赖包
性能提升：这个容易理解，gRPC 是二进制格式，对 REST 明显速度肯定是优势
更高效的推送机制：基于HTTP/2 stream 的服务器端推送机制，效率比基于 long pull 的高，考虑到除了服务发现之后，未来还要做配置变更的通知，而且配置项的数量远远超过服务的数量，这个带来的提升会更大。
这是目前的开发路线图，包括 dolphin 框架外围的一些基础设施，我们预计在年底前能完成微服务框架必备的大部分基础功能。
第三部分 微服务生态中的支撑体系
现在开始这次分享的第三部分，介绍微服务生态中的支撑体系。
首先给大部分正在推行微服务和想推行微服务的同学，泼一盘凉水 :)
不是有了微服务框架就足够的
把框架做好之后，是不是就可以简单的可以在一家公司里推行微服务？我遗憾地告诉大家，这个没有什么必然的关系，并不是你有了微服务的框架，就可以把后面的事情做好。用数学的术语说，微服务框架只是一个 必要不充分 条件。
微服务不是银弹，不能指望微服务单枪匹马的解决问题，“只要微服务一出来，就轻轻松松搞定。” 这种想法不现实。
左边是幻想，右边是现实。
微服务框架需要一系列的基础设施，作为整个微服务体系的基石。
这里面有些是微服务框架的标配，比如实现中央化配置管理的配置中心，管理服务实施服务治理的服务中心。有些是完全和微服务框架没有直接联系，但是又是微服务框架必备的，比如APM/应用性能监控，日志管理如ELK套件等。
在上述的基础上，还需要进一步完善整个生态体系，比如以服务的方式直接提供部分通用功能。
图中是我们在实施中的一些实际例子：
我们在 dolphin 框架中内置加密服务，限流服务，配合实现框架的基本功能。
鉴权服务，统一的短信网关，验证码服务等，这些实际和框架就没有直接关系了，而是作为通用业务平台的一部分
对于 微服务 和 docker，只能用天作之合来形容。
docker 这块我们现在涉猎的不多，暂时还处于探索阶段，后面微服务框架基本成型之后肯定要继续铺开的。
在第三部分的最后，我们总结一下实施微服务的四个要点。在微服务的实施的过程中，要真正的要把微服务做好，必须认真考量这些的足以决定成败的因素：
敏捷是必备的，如果是敏捷都没有做到，微服务真的是“连爬都还不会就想跑”。有时候微服务一上手发现不合适了，做这个东西之前先自问一下，敏捷开发是不是跑起来了，团队是不是用敏捷的方式做开发？
组织决定架构
规划一个技术框架或者是技术路线的时候，需要考虑组织架构是不是和技术框架匹配。如康威定律所说，“组织决定架构”。为了实现服务化，你必须要让你的组织结构做出相应的调整。需要组建跨功能的团队，这个团队一定不是单纯的只有开发、只有测试、只有运维，或者是只有产品，这些功能应该都在你的团队里头。最重要的是要减少部门墙带来的沟通成本。这个墙是非常可怕的一件事情，它可以让一个小时能做的东西，一个星期都做不完。
建议微服务团队按照业务而不是按照技术来划分组织，必须要想办法在一个团队内全栈，让团队自治。这个是我们现在试图想做的，但坦白说这个事情很难,有时甚至是绝望。
产品的思维
一定是产品，一定不要是项目。
产品跟项目有不同？项目是做完就项目交接，团队解散，各找各妈！产品是什么概念？这个产品是你的，你要上线，你要维护，你挖的每一个坑都会以把自己坑进去。这是一个决定责任感的事情，做产品你要吃自己的狗粮，和做项目有质的差异，这个是非常重要的事情。
所有的问题，最终都会归根到人的问题。为了玩的转微服务，你得打造一支能满足高要求的团队，这个要求是真的比较高：产品，设计、开发 、测试都要搞得定，可能是三五个人，甚至七八个人，要一个团队啃下产品线，包括前端、后端、测试、运维和产品。
对大多数公司来说，这四个要点完全做到还是挺难的。前面我们提到的服务化框架，各种技术选型，各种配套的基础设施，都是硬性条件，都是技术性的支撑。而这四点，则更多的是在人文条件方面提出的要求。
第四部分 旧有系统的迁移改造
下面我们开始最后一个部分的分享，谈一下我们最近的一个实际例子，在这个例子中我们是如何改造我们的一个App架构和团队，来实现微服务在实际产品中的落地。
这是我们的ppmoney理财App(也就是前面说的80%营收的核心产品)，原有的架构足够简单而原始：
app和服务器后台是常见的Restful
中间是一个巨型的服务器后台程序：很要命，因为所有代码都堆在一个WAR中
底层还好，一些基本功能被封装成SOA，难得。但是，用的语言是.net，然后通讯机制是以慢著称的SOAP
改造的第一个阶段，我们的目标是引入dolphin框架和实现基本的服务拆分：
首先app和服务器端改用gRPC
引入 API Gateway来负责网络接入，然后按照业务逻辑进行服务编排，必要时在API Gateway中可以使用缓存
将原有的war按照业务边界拆分为若干个服务，每个服务有自己的数据存储，缓存
某些服务可能只是对SOA接口做一个转发和封装汇总
这个工作我们目前基本完成，预计测试通过之后，10月份我们就会上线，逐步替代原有的APP和后台。完成之后系统的性能瓶颈可以得到极大缓解，部署弹性大为增强。
改造的第二个阶段，目标是将现有.net的SOA用Java改写，让前面拆分出来的微服务变成完整的标准微服务。
这个工作还没有开始，坦白说这个工作量比第一阶段要复杂的多，SOA中负责的业务逻辑，相互关联调用的模块耦合，一个又一个的关联查询，挑战极大。
我们再讨论一下人员和团队的问题，好的团队从来不是天上掉下来的，因此如何打造团队成为重点。
在这里我们的做法是这样，分两步：
把架构部门打造成高素质的敏捷团队
这个是必须的，这个如果做不到，后面没得玩。
然后再孵化满足要求的新型业务开发团队
这个地方有一个很逗的词，孵化。为什么是孵化呢？因为很多时候情况下，即使你做到了第一步，你也仅仅是有一支架构部门的团队，而且也不可能满足整个公司业务各个产品线的需要的，你还要把整个的业务线的开发团队提升上来。
如何做到这一点很重要，要想办法自己去培养、改造业务团队。我们称之为“孵化”，就是带领一支业务团队，跟他一起去做业务改造，在改造的过程中，顺带将新的团队带起来。过程感觉就像孵小鸡一样，需要耐心，需要投入，新的团队开始很弱小，但是未来的成长值得期待和投入。
这里依然要继续给大家泼凉水，理想和现实之间的差距，往往是远超事前的想象。
下面我们以过来人的角度(其实也只是才上路)，给大家分析一下微服务推进的实际道路中常见的问题和难点。
计划一开始都是很美好，但是在实施前，请先自问一个问题：资金、技术、专家，这三者是否已经齐备？
这里有个很有意思的故事：就在今年，习总书记访问英国的时候，英国BBC记者问“英企能否在中国投资建设核电站”，中国驻英大使刘晓明反问：你们有资金吗？你们有技术吗？你们有专家吗？
我们为什么要提这个话题呢？因为一个公司要真正的提升上去，也要问一下自己有没有这三个要素：
第一个是资金，你要组建团队，要在整个公司推广，把所有的流程都走通，投入巨大；
第二个是技术：前面我们罗列了一堆
第三个是专家：尤其是在业务团队，尤其是中小公司，一般业务团队只有一两个核心开发人员，有时甚至一个都微服务的都没有，更恶劣时，连一个有基本架构设计基础和模块理念的都没有
特别强调：第三点尤其致命，而且通常都是被高层忽略或者不认可，后者带来的问题更加麻烦。
注意，虽然说微服务不是银弹，但微服务真是一个大炸弹！
微服务所带来的变革是巨大的，当推行服务化，推广微服务框架的时候，远不是简单的微服务框架的技术推广问题。这个事情远比用mongo替代mysql要严重的多。推广微服务，往往是在实际上推翻整个公司的开发流程。
微服务是真正意义上的颠覆性变革，或者用另外一个词会更准确：革命！
要推行微服务，要把这些东西通通跑通，而且做顺、做好，你的微服务框架才能真正落到实处。如果有一个卡住，就会发现经被念歪了，或者走路的时候感觉是腿瘸了一般。
再一次重申康威定律！
对于任何一个试图推行微服务的架构师而言，康威定律是一道绕不开的槛。如果没有高层强力支持并愿意为此调整组织结构，就必然在这里遇到无法逾越的阻碍。
这个画面绝不是只会出现在漫画中...... 请做好心理准备。
谢谢大家参与今天的分享，我们的内容到这里结束，谢谢大家！
最后澄清一下：在之前的分享中曾经介绍了我们的开源计划，原定是在2016年底在 github 开源。
但是，最近有些意料之外的变动，开源计划预计短期之内难于实施。虽然不排除未来开源的可能，但是至少短期之内是无法如我期待的和大家见面了。对此个人深表遗憾，也万分抱歉，请大家谅解......
问题1：微服务和服务化的关系是什么？
服务化是微服务的超集，服务化在很早之前就提出并推行，典型如SOA。而微服务是最近才兴起，和服务化的最大差异在于微服务明确的在服务化的基础上将粒度调整为不能再小的"微"，同时明确提出必须做到两点：1. 独立进程 2. 数据分离
服务治理应该包含那些内容，现在有那些工具可以用？
问题3: 请比较一下各技术堆栈，如果搭建微服务，最佳工具是哪些？
这两个问题都比较大，不是三言两语能阐述清楚，每个话题都够再来开一两回今天的演讲 ~0~
比较巧的是，在10月15日的中生代线下活动中，我会带来一个新的演讲，主题是如何利用开源社区来搭建微服务系统，届时会有详细的介绍和讨论，欢迎关注。
问题4： 使用微服务后，业务接入有没有量化数据，说明效率提升？
暂时还没有量化数据，因为我们最大的系统还没有正式上线。只能给出一个比较有意思的数字：在过去的两个半月中，我们正在加班加点的进行前面分享的这个app后台系统的重构，标准的996加班方式,然后目前测试中，全程我们将bug控制在个位数，速度和质量都非常理想。
问题5：这个服务化框架的性能怎样？系统测试过吗？
简单测试过，服务器端空实现在普通i5主机上跑大概能有14w的 QPS。一些典型的简单业务场景，如简单访问一两次redis，大概几万 QPS。不过现在还没有时间进行深入的性能优化。
问题6：请问如何通过设计提高代码质量
在微服务这个话题中，通过微服务的理念，将系统拆分为小的粒度，开发团队也跟随系统拆分为小的团队，开发人员可以集中在小型的系统中，这本身使得开发人员容易把握全局。简单归纳为，大事化小，分而治之。
问题7：谢谢老师的分享，本人最近也在看 spring boot，java做服务动辄几百兆，我想了解一下贵司选择它是否有更深的原因
在分享中有给出来，你可以回头翻到那页PPT，理由都列出来了。个人对 spring boot 非常认可，使用方便，而且会 spring 的人也多。
问题8：1.前面讲到的规范化，可重用，真敏捷，自动化也是架构师在推吗？2.你对docker什么看法？
是的，也是我们基础架构部门在力推。2. 我对docker很认同，和微服务简直是绝配，下一步必然要上docker的。
问题9：grpc 没有服务治理的部分 这部分你们有什么好的实践嘛？
grpc 有 name resolver，我们用来实现基于 etcd3 的服务注册和服务发现。另外 grpc 内建了负载均衡的支持，1.0版本之后基本可以拿来用了。我们最早在 0.10版本的时候这两个组件都不完善，我们放弃了他们自己实现了，但是1.0之后现在打算换回 grpc 自己的实现。其他的服务治理功能，打算自己动手，当然如果开源社区有合适的组件，我们会在评估之后直接拿来用。
问题10：你上马那么多技术，都是新技术，有没有考虑过这些技术的升级给你带来的影响？
这是一个非常尖锐的问题。坦白说，在今年三月我决定选择自己搭建微服务框架，而不是继续dobbo，然后又选择了grpc/consul(后来换成etcd3)等新技术时，风险是非常大的。当时这几个项目都还是beta甚至alpha状态，我们比较幸运的时在最近几个月，grpc 1.0/netty 4.1/protocol buffer 3.0/etcd 3.0，这几个最重要的技术栈都陆续正式发布，而我们最大的重构项目10月才上线。有种很幸运的感觉。
问题11： etcd3是做什么的，感觉没怎么用过，使用场景是什么和dubbo+zookeeper相比有什么不同
etcd 和 zookeeper 类似，都是实现分布式的一致性，不过 etcd 底层是 Raft 协议，稍微简单一些。
etcd 3.0 是 etcd 最新的版本，因为通讯协议从rest换成了grpc，所以我们在最后时刻选择了它。
问题12：“通常来说的微服务框架覆盖的都是服务器端，不同的的服务器之间的调用。但是这里我们会有一个非常重要的需求，我们必须要把手机App覆盖到。” 为什么要加这个需求？ 请问一下这个怎么理解？框架层面做了些什么呢？
不是要加这个需求，而是我们本来就有这个需求。分享中我们给出了一个数字，80%，这是我们手机app端占我们总的业务量的比例。因此我们在选型时，特别认同google对grpc的定位和要求。框架层面自然是以grpc为主要通讯协议，统一了app端到服务器端，和服务器端内部之间的通讯，由于etcd3的缘故，现在服务注册和配置管理也是统一为grpc了，这算是个意外，令人高兴的意外。
问题13：微服务的粒度怎么划分，能结合业务场景简要说明下吗？
这个问题还是太大，有机会单独再出一个专题来讨论和分享。坦白说，现在我们自己也是在摸索，在实践中调整。
问题14：“底层还好，一些基本功能被封装成SOA，难得。但是，用的语言是.net，然后通讯机制是以慢著称的SOAP”，soap的性能虽然很低，但是可以提供企业级的安全特性，而且支持原子事务，这方面在互联网金融的应用场景下是怎么考虑的？
实际中我们现在的老系统，SOAP的这些特性都没有使用上。关于安全，我们会使用标准的SSL加密，这个grpc有支持，然后我们会搭建自己的鉴权服务。事务方面，现在主要还是尽量用数据库事务做强一致性，或者事后补偿来实现最终一致性。这块我们目前还没有形成足够完善的机制，后续努力中。如有所得，再来和大家讨论。
问题15：微服务的力度如何把控，拆分过细会影响性能
这个问题和前面的问题13类似，以后再细聊。的确在度的把握上，有很多讲究，需要权衡很多因素，除了业务边界和领域模型之后，性能，事务，安全都是需要考虑的。
问题16：用thrift如何？
我们选择 grpc 的一个重要因素是因为 grpc 支持 android 和 iOS，这是决定性的因素。另外 grpc 基于 HTTP/2 实现的 流 也是一大杀手锏，做服务器端推送优势太明显。再有就是不再需要多个连接和连接池，也简化了很多问题。thrift 理论上性能要稍微高一些，不过 grpc 也足够用了。
最后做一下广告， dolphin 框架使用了很多目前业界最新(绝不夸张，都是2016年才release)的技术栈，很多技术基本都没有中文资料，因此我自己写了一些学习笔记，里面翻译了部分官方的英文文档，如果感兴趣可以一起研究：
gRPC学习笔记： https://skyao.gitbooks.io/leaning-grpc/
Protocol buffer 3学习笔记：https://skyao.gitbooks.io/leaning-proto3/
etcd3学习笔记：https://skyao.gitbooks.io/leaning-etcd3/
consul学习笔记：https://skyao.gitbooks.io/leaning-consul/
分享者简介：
敖小剑，PPmoney资深架构师，14年软件开发经验，对敏捷开发，架构设计有深入研究，曾在亚信，爱立信，唯品会任职。现任ppmoney基础架构负责人，负责Dolphin微服务架构和配套基础设施的开发，推进公司全面服务化。
本文转载自微信公众号 中生代技术 freshmanTechnology
版权声明：本文内容由互联网用户自发贡献，本社区不拥有所有权，也不承担相关法律责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件至： 进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容。
用云栖社区APP，舒服~
【云栖快讯】数据库技术天团集体亮相，分享一线生产实践经验，告诉你踩过的坑、走过的路，都是老司机，靠谱！干货分享，不可错过！&&
提供了高性能可伸缩的容器应用管理服务，支持在一组云服务器上通过Docker容器来进行应用生命周期管理。
一个基于高可用分布式集群技术构建的服务API开放平台，帮助企业打通内外新旧系统，实现跨技术平台、跨应用系统、跨企...
针对日志类数据的一站式服务，用户无需开发就能快捷完成数据采集、消费、投递以及查询分析等功能，帮助提升运维、运营效...
为您提供简单高效、处理能力可弹性伸缩的计算服务，帮助您快速构建更稳定、安全的应用，提升运维效率，降低 IT 成本...
2017杭州云栖大会火热抢票
Loading...