待做的：
学习框架：nameko、double、spring cloud、书
微服务的定义：
一些协同工作的小而自治的服务
微服务的核心思想：
1.自治：
1）每个微服务（APP）可以独立部署到PAAS（platform as a service）上
2）作为服务方，需要避免方暴露过多给消费而产生耦合，从而降低服务的自治性。要封装好，服务方内部实现修改，不该影响到消费方。
2.细粒度：
1）解耦：避免系统臃肿、难以维护
2）内聚性：相同的东西放在一起
3.隔离性：
1）各服务直接均通过网络调用进行通信（而不是代码调用），避免了紧耦合
2）各服务之间通过API调用，API解耦性必须要好，以保证技术的选择不被限制
3）一个黄金法则：你是否能够修改一个服务并对其进行部署，而不影响其他任何服务？（独立部署）
微服务的优点：
1.细粒度-》扩展性好-》可以快速响应变化、快速交付-》可以尝试更多的新技术
2.增加了团队的自治力
3.技术异构性。可以根据不同的业务场景，选择不同的技术，来构架服务。比如某个APP对性能有特别高的要求。或者某些APP对底层数据库有特别的要求（图数据库、文档数据库、关系型数据库）。这点需要APP足够小，可以快速重写，从而降低风险。还有就是框架要支持多语言开发业务模块。
4.弹性（稳定性、可用性）：第11章，详解
5.扩展：可以很容易把独立的服务，分割出去独立部署。通过构架来节省成本
6.简化部署：各服务可以独立部署，单个服务出错，也不会影响整体运行。风险可控，成本不高。
7.与组织结构匹配，可以组建小团队自治。第10章，详解
8.可组合性，第5章，详解
9.对可代替性的优化。可以有信心，也比较容易重写系统。（方便重构）
微服务的相关技术：
1.领域驱动设计
2.持续交付
3.按需虚拟化
利用云技术，按需创建机器并调整大小，方便扩展
4.基础设施自动化
5.小型自治团队
6.大型集群系统
分布式系统
7.共享库，要慎用，可能会成为耦合点（第4章再介绍）
关于团队：
1.拆成小团队，对自己的服务的全生命周期负责
2.团队自治
3.研究新技术，来实现自己的服务
构建微服务：
设施自动化
测试：
自动化测试，服务接口跑测试脚本
持续交付：
自动部署（日常、线上），自动测试
关于业务层：
1.使用“领域驱动设计”，先把业务场景确定，然后进行领域设计抽取模型，然后按照模型设计系统
2.业务边界来确定业务层各个APP的服务边界。所以对业务边界的划分很重要。可以根据领域驱动设计来划分
3.关于APP划分的几个思路：
1）.时间维度：短时间内可以完全重写
2）.复杂度维度：觉得够小（可控），就可以
3）.团队维度：保证在一个小团队可以维护的范围内（康威定律，团队的组成，决定系统的架构）
4.APP越小，微服务带来的优缺点就越明显
5.微服务，小APP的缺点：管理复杂
服务管理：
1.接口管理：接口记wiwi、利用工具（？）
注意：
1.微服务的技术，比微服务的理念要变化快很多。所以要更多的关注设计思想，而不是某项技术
2.共享库（lib,前端框架）在微服务框架里，容易成为一个耦合点。不一定是个好注意
待研究：
接口注册，接口发现，统一管理
待学习：
1.持续交付理论
2.Alistair Cockburn 的 六边形 架构 理论（ http:// alistair. cockburn. us/ Hexagonal+ architecture） 把 我们 从 分层 架构 中 拯救 出来， 从而 能够 更好 地 体现 业务 逻辑。
3.寻找一款好的建模工具，用熟他
4.构架原则（根据自己环境制定）https://www.12factor.net/
思考&问题：
1.每个服务端口的配置，接口URL是否能够统一管理？利用自动化部署工具，解决配置管理问题（日常和线上环境配置独立维护）
2.解决服务接口管理的问题，就可以大大降低服务管理的复杂性？寻找一个接口自动生成的工具，这解决了两个研发中常见的问题：（运行时框架的接口采用了 GraphQL ，并且告别了手动写接口的形式，全部利用视图勾选生成）
杜绝了手工约定接口时可能出现的拼写等错误。
能自动统计到所有对某一接口进行消费的页面，一旦接口进行调整，可以自动通知到下游，甚至能自动生成适配代码，不影响下游。
关于数据库：
1.数据库最好使用同一个技术栈的。除非有特殊的需求。方便管理和部署
关于技术异构与标准化：
1.APP内部可以实行技术异构，但是外部框架最好使用统一标准化的技术实现
关于构架师：
1.保证团队有共同的技术愿景，帮助程序员向客户交付他们想要要的系统
2.构架师不像建筑师，而像城市规划师。
3.构架师，不仅要考虑系统、用户。还要考虑开发者，运维人员的情况。
4.构架师，应该更多的关注服务的边界和区域之间的事。至于服务内部，应该给业务留出足够多的自治空间。（当然，最好也能提供一条框架模版）
5.构架师必须要要有时间和开发者一起工作，关注他们的开发效果和体验
6.构架师很多时候是在做取舍。而这些系统架构上的取舍，要根据以下几个原则来制定：符合公司战略目标、根据制定的原则（规范）、根据约定的实践（用任种技术）。通过示例代码和工具来实现
技术债务：
系统避免不了会产生一些技术债务，可能是临时项目，可能是系统目标发生改版。构架师应该要能察觉到它，并引到开发人员去消除技术债务。
代码治理：
1.范例。来自于真实案例，减少出错的可能。你写的漂亮代码
2.服务代码模版（代码库如springboot、tornado）。不应该是构架团队出，应该是业务团队商量出，或者收集意见专人维护（如webx）。内部开源也是个很好的办法。注意，它不应该是强制开发者使用的，否则会影响团队士气。代码模板可能会带来问题导致耦合（第4章讨论）
格言：
1.“你总提及的那个词， 它的含义与你想表达的意思并不一样。”
2.“规则对于智者来说是指导，对于愚蠢者来说是遵从。”
3.治理通过评估干系人的需求、当前情况 及下一步的可能性来确保企业目标的达成，通过排优先级和做决策来设定方向。对于已经达成一致的方向和目标进行监督。
来源：https://www.cnblogs.com/xujanus/p/8617249.html