DockerInfo大家好，我是 吴敏( Mien Wu ), 来自于 上海水道电商，很高兴有会机在DockerOne的分享会上与大家进行交流。
“水道电商” 是一个今年刚成立的创业公司，这是公司及我个人的简介，大家过目。公司注册在上海，我常驻在北京。
作为一个创业团队，在 “除了追求以外，什么都缺” 的情况下，我们积极采用微服务架构开发，由于较传统架构的确有不少变化与需要注意的地方，借些机会把我们把一些经验分享出来。
今天的分享时间不长，半个小时可能没有机会讲的太深入，如有兴趣的话也可以在Q&A环节中沟通。
在过程中，如果对于某一部份内容很感兴趣，大家可以当时发个笑脸，然后面我可以更详细地解释。
上面的内容提纲，我主要介绍前面4点的内容，后面两点如大家感兴趣的可以再聊。
今天不普及概念，也不比较架构的优劣，更不讨论其成熟度等话题，需要的朋友可以参考其它资料，DockerOne.io 社区也翻译了Nginx官方博客中关于微服务的系列文章。 （比如，http://dockone.io/article/394等）
PS推荐阅读：微服务架构目录
记得多年前，大家关心的最多还是C/S架构或B/S架构。历史的车轮滚滚至现在，大家都在聊微服务架构。
众所周知，现在一款软件，需要适配很多客户端 IOS, Android, H5 Web, 甚至包括微信公众号这样奇葩的客户端也需要集成。
一款软件，PM或领导奇思妙想并美其名曰试错，需求月月改、周周改、甚至天天改的情况都有。
一款软件，可能由于中国网民数量之庞大，众多网民之无聊，分分钟就可能制造网红，引发热点，流量爆发。
所以，在多客户端、高度可扩展、高可用等等需求下，应用程序架构高被迫进化，当下的热点之一也就是微服务架构。
微服务架构在开始流行之时，即带来诸多变化。
简单理解这个变化，从组织开发的角度来看，可以看作是集体活动与小组活动的区别，也可以看作是 “集体生产制” 到 “家庭承包制的转变，还类似于80年代工业生产管理中，由 “单件流作业”到“细胞式生产方式”目标都是为了符合需求，更有效率。这种改变引发方方面面的变化，从需求、架构规划、编程、测试、文档、集成、发布等等都带来变化，所以现在通常只有具备一定规模的公司才能有效组织微服务架构的开发。
流程上：
单体架构下，大家更多的是集中确认需求，集中设计架构，集中编程开发测试，集中写说明书，集中发布。
在微服务架构下会变成多个一组组的（需求、开发、测试、文档、发布）过程。
用户权鉴上：
在用户权限上，对于网络应用，大多是将用户登录信息通过Cookie来传递，但在微服务架构下，有可能不支持Cookie的，怎么进行通处理？
在开发人员的分配上：
以前很可能是按，应用架构分层进行分配，但在微服务架构下，更多地需要开发人更全面的技能，甚至是是全栈，或全能的。
众多变化下，我们先说聊聊关于在微服务架构下用户权鉴的处理。
用户身份识别，用户权鉴是绝大多数应用所必须的项，可能也是微服务架构中存在的最大的变化之一。
我们先以 B/S应用，SOA， 微服务架构 为例进行对比，了解其在这个问题上的区别。在用户登录上可以看作是 “单网站登录”－＂ＳＳＯ单点登录＂－“联邦登录”的逐步进化。
在一个现在应用中
常见的多端通信有可能会非常复杂
客户端多样性、代表不同用户、无状态请求 对传统方式构成了挑战。
需要 如何授权、如何存储、何种格式、如何通信、又如何鉴权？
解决方案就是从多世界级大公司都已经在采用的 OAuth2.0 + OpenId Connect
相关概念可以参考
http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html
，http://openid.net/connect/
中的内容。
不过标准只是一纸规范，并不能开箱即用。
我们团队在实践后，建议有兴趣的朋友们分三步（如图）
其中，专门列一个熟悉概念，因为一旦选择 ＯpenId Connect会面临大量的新名，需要去理解。
实现了OpenId Connect的框架，基本每个语言下都有，大家可以根据自身的情况选用。
其官方网站 http://openid.net/developers/libraries/ 有列出来。
接下来说文档的事
之前有个开发的朋友说，程序员都不会写文档，我没调查过，不过文档化对于微服务至关重要。
因为原本在单体架构中，可能不需要文档都能调用。但在微服务下，一般都需要文档。
也对文档化提出了更高的要求。
为了适应用开发需要， 我们在文档化方面提出的需求如上图。
最终是决定，基于一些开源软件自建了文档服务。
这页PPT中，是我们文档发布的流程。
没有用OFFICE, BLOG, 以及一些SAAS主要是因为工具切换，文档组织管理不方便。
这种方式应该是程序员喜欢的方式，开发工具 与书写工具一致。
我们用了几个月后，也的确是顺畅的。 当然也存在不足，条件有限的情况用着还不错。
关于测试的事
一般而言，软件开发中测试的项可能包括：单元测试、集成测试等等
理想的情况是，开发人员写好单元测试、完整的集成测试的项目，需要时就跑一遍。
但对于我们这样的创业公司，恨不能拿开发人员当牛使，如果有更EASy 的办法，能少写一个测试项目就是少写一个测试项目。
在开发过程中可以使用 Swagger UI 进行可视化的测试。
但Swagger UI并不方便跑批量的测试，所以我们的做法就是，先用Swagger 导入JSON，做适修改并加入测试脚本后，由POSTMAN来中跑批量测试。
由于这样做并不需要较强的编程知识，人员上会比较好按排一些。
好的，已经超了10分钟。前面说的主要的4点就分享到这里。
好的，感谢嘉宾@MienDo@北京-水道电商 ，现在是提问时间
Q1 ：想问下咱系统pv uv在什么量级？会存在峰值的压力请求么？峰值来时使用微服务+容器可以弹性扩展服务，关闭时效性要求不高的服务，资源优先分给时效性要求高的服务。我们有在这方面有什么实践分享和问题没？
A： 目前，我们的产品还没有最终上线，因为是toB的业务，PV\UV上前期不会太大，暂时预计也不会存在峰值压力， 在负载均衡方面后期可分享。 采用微服务架构，主要是考虑高度可扩展，及适应用多终端。
Q：可以介绍一下自建文档服务都用了哪些开源软件吗？是否带来额外的维护负担？
Ａ：任意支持MarkDown的编辑器 + Git server + Gitbook + Docker + node + linux server , 可以做到全免，但是GIt Server, Server的费用视自身情况。
Q：交流3群Q3：能否介绍你们的微服务持续集成和持续部署方面的经验？
A： 因为我们团队人力有限，持续集成方面采用的第三方SAAS服务，布署方面，是采用 git webhook .
