web项目分类：
1. 全新从头开始研发的项目；
2. rebuild/refactor一个已经运行良好的项目；
3. 开发新的功能
微服务架构切入模式探讨
一般来说，一个产品预计刚上线时并不会有太大的并发量和访问量，那么从头开始研发的项目可以使用传统的单机模式快速开发部署验证，后续再做一个一个模块的重构部署为微服务的模式。
当然，在最初的开发时就应该考虑到将来的微服务化。
单体模式/微服务模式与系统复杂度开发效率的关系
需要微服务架构的信号
1.应用变得越来越复杂和庞大，以至于新的开发人员需要太长的时间去理解，这会导致组织和项目的功能扩张会成为一个重大的问题，每增加一个功能变得风险越来越大
2.应用的不同部分具有独立的完全不同的更新频率
3.系统的不同部分可能会强制开发人员使用一种语言和框架去开发，比如web主项目使用PHP开发，而人工智能model更多的是用python训练和服务，那么就需要考虑使用ptyhon开发人工智能模型预测服务
web service:
a way to expose the functionality/data of one application to other applications using http
micro service
a service oriented architecture(SOA) of developing software applications such that the application is made up multiple loosely-counpled and independent modules
API
the language used by different modules and applications to communicate with each other.
微服务系统设计原则
High Cohesion
single focus并且do well, SOLID(single responsibility),only change for one reason.类似于OOP中的类，类将相关的数据集方法打包成一个类
Autonomous
松耦合，面向接口的编程。
微服务应该是无状态的，无需记忆以前的状态。
backward compatible也是很重要的，否则一个微服务的变更，必将导致其他服务的兼容问题。
定义清晰的input, output保证多个微服务可以同步进行开发
Business Domain Centric
每一个service可能对应着一个business function，和组织的架构相映射。
Resilience
如果一个微服务down,相应依赖他的微服务应该能够downgrade，并且微服务可以通过注册服务到管理单元，以后就route服务到其他的微服务单元。
Observable
需要有central monitoring, central logging监控系统的健康
Automation
需要持续集成CI，testing，deployment
Hosting platforms
virtualization
containers
self hosting
registry and discover
新项目开发面向微服务的探索
由于新项目中系统的需求和边界可能并不是非常清晰，同时如果团队本身对微服务并不是非常擅长，则建议还是先以单体模式快速开发产品，随着产品的试用对不同domain之间的边界越来越清晰，那么就可以开始重构系统。首先将具有公共服务性的模块做成一个微服务，逐渐演进。。。
微服务架构技术栈总图
API网关在这个体系结构中起到非常重要的作用，他是对外暴露的唯一接口，他接收用户的访问请求，并且代理路由所有的微服务请求并且变换转发结果给用户。比如kong gateway是非常强大的api网关产品
微服务的持续集成与部署
docker jenkins,gitlab,k8s
https://www.cnblogs.com/java-zhao/p/6065268.html
总体流程:
- 在开发机开发代码后提交到gitlab
- 之后通过webhook插件触发jenkins进行构建，jenkins将代码打成docker镜像，push到docker-registry
- 之后将在k8s-master上执行rc、service的创建，进而创建Pod，从私服拉取镜像，根据该镜像启动容器
https://blog.catscarlet.com/201612082623.html
https://zhuanlan.zhihu.com/p/21563604
Docker
Docker解决了微服务架构下，服务的粒度细服务数量多所导致的开发环境搭建，部署以及运维成本高的问题，也可以大大降低随着微服务数量增多所导致的节点数量增多的成本。
SOA vs 微服务
SOA:将服务分解成多个子系统来实现，粒度比较大，基于企业服务总线，集中式的服务架构，属于单块架构系统，相互依赖，部署复杂，集成方式依赖于SOAP/ESB/WS等重量级协议；
微服务则自底向上开展实施，一个系统被才分成多个粒度精细的服务，集成方式为HTTP/REST/JSON轻量级协议，无集中式总线，服务能够独立部署，特别是基于docker技术。
总的来说，微服务是传统SOA的一个子集；
微服务vs共享库
微服务通常与语言无关，平台无关。
微服务提倡围绕业务组织团队，微服务的模式往往要求团队成员更有多样性的能力，不像传统的安装技术能力范畴划分：前端，后端，用户体验UI等团队。
微服务架构属于产品导向，比传统的项目导向使得团队更有主人翁意识，负责整个服务的整个生命周期。从服务的分析，开发，测试，部署到运维每个环节都要有服务的团队成员来负责。
实际上我可以这样理解：每个服务都是一个scrum团队，有前端ui，有前后端开发，有测试，有dba人员，是一个战斗的团队。多个scrum team组成整个产品的master项目。
技术选型
对于传统的单块架构系统，最初的技术选型将严重制约限制将来的技术演进能力，如果想尝试新的编程语言或者框架，是非常困难的。而微服务架构则可以依据评估服务的重要程度以及团队的能力选择一个服务作为试点切换语言或者框架，快速完成，成功后可以应用到所有的服务模块，甚至就使用不同的语言和框架。
jenkins是一个java编写的开源CI/CD系统
https://jenkins.io/
单点登录SSO
https://www.cnblogs.com/liuche/p/7955462.html
https://blog.csdn.net/why_2012_gogo/article/details/74137631